On Wed, May 4, 2016 at 4:23 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Wed, May 4, 2016 at 6:34 AM, Krinkle krinklemail@gmail.com wrote:
[..] We don't currently require modules to say whether they are a
dynamic module.
Maybe we *should* require that.
Then that could allow us to [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 [..]
Agreed. Though I'd like to tackle that separately in https://phabricator.wikimedia.org/T127328. See the section about removing "position" and adding a module type property.
On Wed, May 4, 2016 at 4:23 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Wed, May 4, 2016 at 6:34 AM, Krinkle krinklemail@gmail.com wrote:
For gadgets we can try to infer the intent [with] a way to [declare]
explicitly.
A gadget might want both [..]
I acknowledge this use case. We are no longer allowing hybrid modules (which were never intentionally allowed, and don't properly work as demonstrated by the styles loading twice), but the idea of providing both is valid.
In such case one merely needs to register them separately and declare a dependency. Similar to what we'll do for the user/site modules, and like we'll do for oojs-ui.
Since the styles portion may not be useful for end-users directly, such module can be registered as hidden gadget. This concept is relatively new, but should work fine for now. (Back-ported from Gadgets 2.0.)
On Wed, May 4, 2016 at 4:23 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
[..] But don't we have the corruption anyway? [..] module 'foo'
is changed so it also needs 'bar', so page Foo now has to call
addModuleStyles( [ 'foo', 'bar' ] ). [..]
The corruption I hypothesised is avoided because by design, page styles modules may not have dependencies. If a module 'foo' ignores that design requirement and changes regardless to require 'bar', then that change is in error and should be reverted.
There is no one way to make everything easy. In designing RL we saw two ways to make style modules work, we choose this way. It makes most cases easy, and some cases like this a bit harder. But unless it makes valid use cases impossible, it's imho a worthwhile tradeoff.