We're in the process of moving FROM https://gitter.im/dart-lang/angular – if you're looking for old conversations
Created the task angulardart-community/angular#7
@gzgavinzhao:matrix.org if no adjustment/concerns, please assign it to me, so I will start to work on it.
@gzgavinzhao:matrix.org if no adjustment/concerns, please assign it to me, so I will start to work on it.
@gzgavinzhao:matrix.org created a pull request to rename angular packages, could you please review angulardart-community/angular#8
Whoever wrote the tests for Tour of Heroes Part 5, I really want to smack my keyboard right now
Just migrated
pageloader to null safety. If you're using pageloader, please checkout the prerelease to see if there are any issues. You can drop it in directly without any code changes.
I'm still fighting with the
analyzer. That is the last problem for it.
That is not urgent since we can still live without it, so no need to rush on that :)
Also on the second thought, I'd recommend doing that after I finish bumping the
analyzer to version 4. The code (and even the logic) might have to be changed and merge conflicts might happen.
Which is one of the conflicts I don't like to deal with.
I am worrying there are more then only one active branches are used in ngcomponents. It will be painful to merge them.
Could we merge them as early as possible, and we would work on only one trunk branch, so the maintenance and integration would be simpler, and the project would be improved with every successfully merged and tested commit?
Let me know if I can help here, please.
Could we merge them as early as possible, and we would work on only one trunk branch, so the maintenance and integration would be simpler, and the project would be improved with every successfully merged and tested commit?
Let me know if I can help here, please.
In
angular_components, only null-safety and new-dev are considered active branches. The rest were all sort of temporary branches cut out so people can just drop our package in without any changes to the code.
For
new-dev and null-safety, usually how it works is that I migrate files in null-safety one by one, then I check dukefirehawk's work in new-dev, see if any of us missed anything crucial, then commit. This is also why you often see commits marked as "authored by dukefirehawk, commited by GZGavinZhao".
To some extent, one can say that
new-dev is being hand-merged into null-safety bits by bits.
angular_components is a very complex library (as seen through the struggling of dart migrate) and sometimes it can be hard to wire the logic around, especially when the original authors didn't write it thinking that someone outside of Google will be migrating the entire project to null safety.
Just to add, there is practically no unit test in the code. So the testing has to be done manually by running the examples and then debug by stepping through them in build_runner or browser. And any changes done, won't be able to tell if it works until running through the examples. So new-dev is a fast track migration to get examples running then fix broken UI issues one by one (Not all are fixed). null-safety is more methodical by reviewing the changes introduced in new-dev and merge with main branch.
The
main.dart is attached to the index.html file so if you separate web folders into dev and prod you will end up having two index.html and any web asset you use
Typically I injected a config class into component's constructor and then have a flag in the config to flip between dev and prod. Only ever need one web folder. For cases where a variant of web app are needed, I just create an index_test.html along with main_test.dart in the same folders. 100% reuse the components. Then just
ngif for minor variations in HTML.
I was about to suggest envify, but I think you can combine these two approaches.
<material-button *ngIf="!noButton && thirdButtonName != null" [disabled]="thirdDisabled" (click)="onThirdClick()" raised
class="">{{ hasModifications ? 'thirdButtonNameChangeModif' : 'thirdButtonName' }}</material-button>
la c'est mon boutton dans mon bottom html
et mon bool = hasMofications = true; se trouve dans Meet_component.dart
Suppose you have directive like this that is looking for @Host() HostService.
@Directive(selector: 'child-directive')
class ChildDirective {
ChildDirective(@Optional() @Host() HostService? hs) {
print(hs);
}
}App template:
<!-- component providing HostService -->
<child-directive></child-directive> <!-- null -->App template:
<!-- component does NOT provide HostService -->
<parent-cmp> <!-- Provides: HostService -->
<child-directive></child-directive> <!-- Instance of 'HostService' -->
</parent-cmp>
So my question is, how do you limit injector to reach only to component (where is created - in his template) and no further.
what is the use case @gtms_gitlab
Has anyone successfully use the null safety (the build_runner version) of
mockito to mock Router objects?
@gtms_gitlab you use this on the
Host Component and in the children component you can inject Artist as in the example
There are also words like
tree and view, and I don't know if this is anywhere explained. Or is there?
Thanks for that advice, but unfortunately it didn't help. My past few days were just spent on trying to figure out why the null-safety
mockito won't mock Router objects.