It recently occurred to me, relatively unprompted, that many of the state management patterns in "modern" "react-ish" webdev are just re-implementations of dynamic scope – with the same advantages and disadvantages dynamic scope has had for the past ~60 years that it's been in use.

(Of course, after noticing this, I checked, and pointing out how not-new this pattern is… is itself not at all new: spin.atomicobject.com/2020/04/ We sure do love reinventing wheels!)

Follow

I might should slightly walk back ^^^ I do think that many of the practices of "modern" web-dev are ignorant re-inventions of previous solutions (we all need more history!), this one seems to have been an *intentional* re-implementation (much better!):

> In React, this is solved by Context. It is essentially like dynamic scoping for components. It’s like a wormhole that lets you put something on the top, and have every child at the bottom be able to read it

overreacted.io/react-as-a-ui-r

@codesections I've never seen a single instance of dynamic scoping where it actually was a good idea, shells included.

@Steinar

> I've never seen a single instance of dynamic scoping where it actually was a good idea

I've seen several (though they're the distinct minority).

Off the top of my head, they're a key part of how emacs can be so extensible, as Stallman described 30 years ago: gnu.org/software/emacs/emacs-p

Raku APIs also make good use of dynamic scoping when wrapping functions without changing their signature (these dynamic variables aren't exposed to the API's user). e.g.: fosdem.org/2021/schedule/event

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.