On Wed, May 4, 2016 at 6:34 AM, Krinkle <krinklem...@gmail.com> wrote:
> ## Implicit type > > Aside from the need for dependencies between dynamic and page style > modules. There is another bug related to this. We don't currently require > modules to say whether they are a dynamic module or a page style module. Maybe we *should* require that. Then that could allow us to resolve one of my pet peeves with ResourceLoader: we can remove the need for general developers to know which modules need addModules() and which need addModuleStyles(). They can use addModules() for all modules and RL can just do the right thing based on the information provided by the creator of the module who is more likely to actually know whether something needs to be in <link> or JS-loaded. Although for maximum benefit there, we would also have to make RL resolve dependencies to collect all the page style modules on the server side (more on that below). This would also be an improvement for general developers, as they would no longer need to know that the module they want to use has some dependency that needs to have addModuleStyles() manually called. > > For gadgets we can try to infer the intent (styles-only = page style > module, both = dynamic module), with perhaps a way to declare the desired > load method explicitly in Gadgets-definition if the default is wrong. > A gadget might want both: a handful of "page" styles to prevent FoUC, and a much larger set of "dynamic" styles that can be loaded asynchronously along with the JS so as to not delay the rest of the page. > [1] If one would allow page style modules to have dependencies and resolve > them server-side in the HTML output, this would cause corruption when the > relationship between two modules changes as existing pages would have the > old relationship cached but do get the latest content from the server. > Adding versions wouldn't help since the server can't feasibly have access > to previous versions (too many page/skin/language combinations). > But don't we have the corruption anyway? Say page Foo has a page style module 'foo', so it calls addModuleStyles( [ 'foo' ] ). Then module 'foo' is changed so it also needs 'bar', so page Foo now has to call addModuleStyles( [ 'foo', 'bar' ] ). What is avoided there that isn't avoided when addModuleStyles( [ 'foo' ] ) is smart enough to internally see that 'foo' depends on 'bar' and act as if it were passed [ 'foo', 'bar' ]? Or what case am I missing? On the other hand, dependencies avoid the case where the developer modifying 'foo' doesn't realize that he has to search for everything everywhere that passes 'foo' to addModuleStyles() and manually add 'bar' to each one. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
