Access context from lifecycle methods (static contextType = X)

[rpiaggio]

We're trying to use React Context in order to avoid passing context objects around everywhere. Although scalajs-react implements provide and consume for contexts, I couldn't find a way to invoke said contexts from Scala components' lifecycle methods.

In JS it's done via contextType: https://github.com/japgolly/scalajs-react/blob/master/doc/CONTEXT.md.

Is there a way to do this in scalajs-react? If not, could I request its implementation?

Thank you!

/cc @cquiroz

[japgolly]

Hey Raul, how's it going?

I just looked up contextType in the React docs cos I'd never heard of it and wow, it seems like quite the piece of 💩 . So each component is allowed to access a maximum of one context variable in it's lifecycle methods with a little hardcoded static field hack. OMG. Ok well I guess I'll have to support it in scalajs-react because it's part of React...

...but I urge any and all users to avoid React context. The amount of bad architecture that spreads through codebases like mycelium just to avoid devs having to pass some arguments around is already too high. If we just manually do the little bit of boring boilerplate to pass arguments around ourselves (and lets face it, we're talking about maybe 30 seconds of boredom occasionally), then code, its dependencies, its relationships, is all explicit and clear to readers. Once you start trying to hide all of that you trade away compile-time safety for runtime assumptions, shouldComponentUpdates become less informed, I mean we all know that global variables are a pretty bad practice right? React context = a (scoped) global variable. Sometimes that's the perfect choice and tradeoff, but in nearly all cases, it's not. Especially when just passing arguments is so well supported and trivial. Not to mention, that there are techniques to reduce argument-passing-boilerplate like creating an Args case class so that only one argument needs to be plumbed around once, or passing a function instead that hides all the arguments and just generates the result you're directly interested in.

Anyway, the above is my advice for anyone considering using React context; what you do is up to you of course and I wish you luck.

[rpiaggio]

Hi David!

After reading your comments, we'll certainly reconsider whether to use contexts. We were just beginning to experiment with them.

I agree 100% that it's a limitation that only one context can be accessed in the lifecycle methods, that caught my attention too.

We are using specialized components up in the component tree that just hold (and provide) context in its state. Reusability for the context is therefore nicely encapsulated there. The one property of contexts I found desirable is that when something changes in them, then the consumer components deep down are updated without triggering any logic at all (I understand) in all the intermediate components.

I'd be interested in hearing more about the alternate techniques you mention; I see you already opened a PR to document those.