On Wed, May 4, 2016 at 6:34 AM, Krinkle <krinklemail(a)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