With nested flexbox the nested dimensions are not aligned to each other.
With grid the items are aligned across both each row AND each column.
With subgrid even nested grids can be aligned across nesting levels.
My favorite Bret Victor talk ever is „Drawing dynamic visualizations“ [1] that made me try to reverse engineer [2] the demonstrated tool that he sadly never released.
Say you want to do obj.child.foo[3].bar += 2 but without mutation, but instead all the data is immutable and you need to do a deep copy along the path.
Lenses are an embedded dsl for doing this via syntax that reads similar to to the mutable variant.
Additionally it allows to compose many of such transformations.
Yes lenses are pairs of functions that allow bidirectional data transformations. One function acts like a getter and one function acts like a setter. The signatures of the functions are designed to compose nicely.
This allows to compose complex transformations from a few simple building blocks.
In the end it is really just function composition but in a very concise and powerful way.
In your cambria example the lens is defined as yaml. So this yaml needs to be parsed and interpreted and the applied to the target data. The rules that are allowed to be used in the yaml format must be defined somewhere.
With pure functional lenses the same kind of transformation rules can be defined just by function composition of similar elemental rules that are itself only pairs of functions.
> So this yaml needs to be parsed and interpreted and the applied to the target data. The rules that are allowed to be used in the yaml format must be defined somewhere.
I wasn't trying to get into the specific technology. The Julia still needs to be parse, and while Yaml has them separate, CUE does not (which is where I write things like this and have building blocks for lenses [1], in the conceptual sense)
In the conceptual sense, or at least an example of one, lenses are about moving data between versions of a schema. It sounds like what you are describing is capable of this as well? (likely among many other things both are capable of)
Yes functional lenses are very good at transforming between between schematas.
You can think of it as an functional programming based embedded domain specific language for transforming immutable data structures into each other. Sure there are other ways to do it but its like generalized map/filter/reduce class of functions vs doing the same imperatively by hand or in other ways
With lenses its possible to create component interfaces that make local and global state interchangeable. Even for focus, selection, scrollposition components use local state by default but that can replaced by a lense into a global state.
This make stuff like synching two scroll positions or selectiom ranges super easy and allows for consistent manual focus management across components.
But what’s the benefit of this approach? It seems needlessly expensive, both in terms of computational overhead (walking up and down the state tree) and how much more code it requires.
I guess you gain persistence of your entire app’s state (which makes time travel debugging easier) but that’s all I can think of.
In my experience when applying this architecture to react or svelte, the performance is quiet good, often better than classic alternative approaches (redux, many local useState)
But the main benefit is not only the persistence of the app state, but composable globally consistent state.
With most state management solutions at some point you hit a wall where communicating state changes between far away components is really difficult. You need to manually manage eventlistener lifecycles, route events through the application and convert events into state changes and state changes into events, while not causing cycles or unstable feedback loops or race conditions.
With lenses the state tree is composed declaratively and locally. each component does not need to care if the parent state is locally constructed or coming from further away.
/edit:
Actually using this approach you are not forced to have a single global state but instead each component can simply decide to embed its child components state into its own state or not.
If all components decide to embed their children state you get a single global state. But if all components decide to not embed their children state you get only local state with no communication. But the unified Interface gives you the choice.
This is very detailed introduction and documetation of a lense-based architecture in react. [2]
At the first glance it looks kind of overwhelming but it contains lots of examples.
This is a case study of many rather complex components. [3] The codinsteade is rather quick and dirty hacked together and at the first glance not really readable but thats kind of the point: even complex components can simply be composed locally from many small parts of requiring some global controller managing the state and keeping it consistent.
In every language there are sharp edges or dirty corners that are just annoying once you hit them. JavaScript and Php are full of inconsistencies, Ruby and Python are nice and the surface but once you dive into meta programming, OOP and mutability complex code bases are just impossible to trust/reason about their correctness. Rust, C++, C#, F#, Java... I could go on.
In my opinion Elixir just hits the sweet spot of good design. After multiple years using it there comes nothing to my mind that I find ugly or annoying.
Sure there are other languages that are quiet nice on paper but often they lack the ecosystem to let you just build production ready stuff.
The Elixir ecosystem is also not that large, but large enough for quickly building a web app or composing useful automation pipelines.
With subgrid the rows and columns of two sibling grids are aligned with each other by glueing them to the rows and columns of the parent grid.