Basically I love object-oriented programming but the problem with the way OO evolved is that classes do "too many things".
Currently trying to move a fairly simple bit of code from one class to another, but it's actually very difficult because classes aren't just encapsulating data or functionality, they become sort of generic "scopes" that bundle together all the utilities a bit of code might need. And all those utilities remain in the original class.
@mcc "but it's actually very difficult because classes aren't just encapsulating data or functionality, they become sort of generic "scopes" that bundle together all the utilities a bit of code might need" -- true & hard to push against this
@mhoemmen It almost feels like we need "classes" and then we need "a second thing" which is like a dynamic scope that follows you around or a thread-local variables table. But I couldn't tell you exactly what that thing should look like.
@mcc @mhoemmen Yes, the thing you're imagining is a "context." A bit of a pain-in-the-ass in most OOPs because it requires every single function in the universe to have a new argument on the front, but they're definitely a concept in other languages (or found in other frameworks... Game development, for example, is quite fond of them since it's common sense that 90% of the code is talking about the same "present state of the game world" so basically a global variable is always available to get that present state).
React offers a neat twist on these in the form of their Contexts. The render tree can include Providers for various Contexts, and anything under that point in the tree that declares itself a Consumer of the Context gets a reference to the Context the Provider maintains. Different parts of the tree could be under different Providers, but you don't see any of this unless one of your React Components explicitly declares it's a Consumer.
I've grown quite fond of this pattern (and its neighbor in React, Algebraic Effects) for taming some of the complexity (although it can add its own, other form of complexity: looking statically at some code that uses a Consumer, you can't know which Producer fed it without tracing the render tree, so it invites spaghetti code if overused).
@mcc @mhoemmen It's frustrating because it simultaneously got better and worse when React moved to functional components... On the one hand, `useContext` is a lot easier to use than the Provider component or the hooks they added to class components to declare they use contexts. On the other hand, it broke the symmetry in the original API that now Providers are part of the render tree but Consumers are an algebraic effect.
@mtomczak @mhoemmen Yeah, I do find React quite pleasant to use. Although learning to use Context the first time is a trip (the interface is just a little bit weirder than it should be… I use a wrapper class 100% of the time)