Right now, every component which does get created triggers the parseConfig() logic in case it has its own view controller.
For model.Component I am using a bottom up approach: Every component triggers the parseConfig() logic on the closest view model, not related if it has an own model or not. This means more parseConfig() calls, but each call only parses the top level config and does not touch items.
I want to apply the same strategy to view controllers.
There are several benefits:
- We can dynamically add new components including string based listeners and dom listeners, not related to an own vc.
- We can immediately resolve references and store them inside the vc.
- Parsing events will get easier: before, the top level config already applied the
core.Observable mixin, so these listeners got transformed, while this was not the case for items.
- We can resolve string based listeners in a smarter way => finding matches inside the controllers parent chain if needed.
In general I think we can simplify the logic and code size by a lot.
I will create sub tickets as needed, already created a new project.
Right now, every component which does get created triggers the
parseConfig()logic in case it has its own view controller.For
model.ComponentI am using a bottom up approach: Every component triggers theparseConfig()logic on the closest view model, not related if it has an own model or not. This means moreparseConfig()calls, but each call only parses the top level config and does not touchitems.I want to apply the same strategy to view controllers.
There are several benefits:
core.Observablemixin, so these listeners got transformed, while this was not the case foritems.In general I think we can simplify the logic and code size by a lot.
I will create sub tickets as needed, already created a new project.