| Somewhat off topic, but this gets at an issue with “components” of all types that I’ve been wanting to get off my chest: > Design libraries are also limited in the type of things they share: just components or symbols. This works great if all your design work is just clicking together new screens with the same components, but anything new will see designers clicking into components and copying over things like colors, font variants and checking spacing just to copy that over into new components. When you copy over things, you’ll invariably make mistakes (we’re just human after all). Ideally, a component system means you’re black boxing some function. Unfortunately every component system I’ve ever seen has a hard boundary at some “material” transition: A UI drawing that can be used inside a design program A React component is bounded at the DOM and can’t handle server side concerns A CSS component is bounded at styles and can’t handle HTML concerns A middleware component that handles authentication, but can't reach outside the routing phase. etc Inevitably then, you end up having two or more tightly coupled components: A front end component + the server API that it knows how to talk to A little HTML widget + a microservice that it feeds with it’s own persistence A container for wrapped content + a little middleware meant to be added to the app that serves the content A button + a delayed job + an email template to get sent when it's done etc In order to do this, instead of just having one module with a tight set of concerns inside it, you have to implement some of your concerns in two places, and you also have to map data into the component interface, and then back out again. In some cases this can be 4x the complexity ("code" vs. "code + write to component interface + decode component interface + variant of code on other side of interface"). If the component could span both domains, it could just move the data exactly where it needed to go, as efficiently as possible, since the data is all internal to the component. The conclusion I’ve come to is something like "components want to be free." I.e. components want to have concerns that can span the entire stack, and implement procedures in arbitrarily disparate kinds of source locations. This of course precludes ALL of the component systems which are confined to a specific material domain. It means the boundary of a component has to look something like arbitrary source code. Component interfaces can’t conform to a single template. That raises the question “what is a component at all?” If the boundary of my component is just a set of function calls, it’s just a module. How is it a component? And maybe it’s not. Maybe components are a local maximum in code cleanup, and I’m advocating people move past them and just write really excellent single-concern modules instead. I don’t know. This is as far as I’ve thought it through. (I do maintain an NPM module called browser-bridge that lets me build arbitrary client/server components, along an event sourcing library called a-wild-universe-appeared for doing persistence in an isomorohic way, and then something called bridge-module for getting dependencies in the browser... All of which let me experiment with what I'm describing, but those are all in a pre-1.0 mostly beta state. The basic interfaces are all stable though.) |
Not quite the same thing as you describe, but it's exploring a similar part of the design space:
http://links-lang.org/