Repository navigation
Conversation
Use the `ProtoViewDto` created by the render `Compiler` to create a `ChangeDetectorDefinition`.
Use the `ChangeDetectorDefinition` object to codegen subclasses of `AbstractChangeDetector` for each `Component`.
- Use looseIdentical - Use DIRECTIVES_ACCESSOR
parallel one another.
Use gulp-template to generate tests from a configuration file. In the future, the config file can be used to generate Dart `ChangeDetector` classes so we can use the same code for testing Dynamic, Jit, and pre-generated implementations of change detection.
There was a problem hiding this comment.
if you do it this way, developers will not be able to iterate on the test without a full rebuild. in other words, this will cause issues for all test.unit.* tasks. A better way would be to integrate this into the broccoli pipeline, but before we do that I'd like to know for sure that generating the test file is really the only way to do this.
It looks pretty insane and unreadable to me.
There was a problem hiding this comment.
I'm open to other ideas - some more background (sorry if this is all old news):
Js creates ChangeDetector classes on the fly with new Function, but Dart's security policy doesn't allow arbitrary code execution so we need to generate those ahead of time.
Each feature we want to test in a template dictates a change in the structure of the associated ChangeDetector, so our options here are:
- Conflate a bunch of tests into a single change detector class
- Have a separate change detector class for each test case
Each has their challenges, and option 2 is what the existing change detectors use so I didn't see a compelling reason to switch.
Generating those classes requires an instance of ChangeDetectorDescription, so the *.config.json file is the minimum amount of information necessary to create one. I'm running a tool against that file to generate the classes in Dart, and my thought is to check those in to a generated/ directory. build.js.test/change_detectors uses that information and the *.jstemplate file to create the Js test file, but an alternative is to pre-generate and check this in as well. That might make things a little more "sane", but it also means every change will require a manual step to re-generate the tests. On top of that, everything will silently pass if you forget to manually regenerate, which is not the case if we automatically regenerate one or the other.
What do you think? Any ideas for simplifying?
|
FYI, we will update clang-format to a new version today (see #2059). So before this PR gets rebaed ontop of master, please do a local clang-format with the newest clang-format locally to minimize merge conflicts. |
|
This served its purpose of discussion, closing now to focus on #1932 |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This is a piece of hard-coded hackery, but it gets generated
ChangeDetectorclasses running inhello_world!Getting this to work brought up a few issues:
preGeneratedProtoDetectorsfor testing purposes rather than allowing another map to be passed in?preGeneratedProtoDetectorswith a thin object that gives some API related to registeringProtoChangeDetectors.ChangeDetectorDefinitionids. I'm setting just using the type name in ViewDefinitionCreator, which matches theidbeing passed in for change detection, but these could collide. We should update to something a bit more unique and share code.HelloCmp_host_0andHelloCmp_comp_0? Are we supposed to be pre-generating aChangeDetectorforHelloCmp_host_0?