Clojurians Log v2

again, I find it a bit strange that all this discussion about the React Fiber scheduler is only happening now even here. This is over 3 year old stuff. It does seem to me that people equate "last major version" -> "least risky" -> "least buggy"

so there is zero interest in anything else because by definition it can't be a better choice

and the react team helps with this by keeping stuff "experimental". Even if it's known that it's much more probable that if your code doesn't work with concurrent mode, you are using bad logic than that there is a bug in Fiber

the scheduler suspends render, that's why by default it is called twice, and that's why at first components sometimes get called with null props, that's state that is not ready yet.

that is all what is required to be remembered, that the render happens on a detached loop that takes state from the rest of the system.

I also like the fact how they used a very minimal system with 2 fibers switching between each other, it's neat and very philosophically/physically correct way to do it

what I don't like is "the rest of the system", they are trying to write a database (I mean, even you talk about ACID here...) inside a UI library.

just no.

also, I find the theoretical talk bothersome, and I don't want to be rude or cynical here, just want to point out that local state is wrong abstraction for UI usually, the data stored is accessed only by implemented methods. and these tie up into a transactional, or REST interface. Machine talking to machine. With user interfaces this is not true anymore. The data you query from your local states all get mixed up into a relatively small screen, overlapping, mixing, etc. Good interfaces can use data from very different parts of the state, so that they give a better narrative, a better story. Which means that your components will have to either expose their local state, effectively becoming tiny little global states that are managed from the leaves of your app, exactly where most of the development work happens, so where most of the editing is done, so where most of the mistakes are introduced. Not good. Or, what React says, you lift the state up: https://reactjs.org/docs/lifting-state-up.html As I said, I consider this documentation page an admission of failure. This literally says you should always have a shared component for all your shared data. But that's terrible if you have mostly shared data. Furthermore, the whole thing with the flux pattern or the Elm Architecture or what redux/mobx do is to have a manageable way to do this global state where you eventually end up with, at least if you do user interfaces with lots of interconnected components. Making the communication layer explicit and the state external (global) doesn't mean that all your components suddenly can overwrite any state, since a pub/sub pattern can also check for whoever wants to write whereever and you can implement any logic over that check compiletime or runtime even. Also doesn't mean that they have to see everything since it's possible to create react elements in a way that you feed them only the data they need (like om/next)

https://gist.github.com/ashnur/f2fb2cf230d47aea9a63123aedb5926a this is how I solved last time in javascript the communication layer.

the comments are a bit misleading, those are more like compromises than actual problems

the only realy bad part is where I use window, but it was more of a demo and we didn't know how to actually handle state, and after I wrote this, react released Hooks, so it became somewhat redundant

Hooks are a better fit for what I do at work, where we almost never have lots of interconnected data, just big forms

This is intriguing, but hard to follow right now (for me). Is there a design document that could describe the high level architecture of the gist you pasted?

I think this is too general for a design document, but maybe I misunderstand the question.

Right, big forms/interconnected data - the trade offs are different which is why it’s hard to even have a discussion about state management. Of course in a long lived product what starts as a small form will graduate in 2 years to something g more complex.

the good thing about forms is that you have clear state transitions, so even in the worst case scenario, you can interrupt the user with errors and such

In a more dynamic application it can be bad UX to start dropping error elements everywhere inside the page

I’m not sure I understand if you’re advocating for global state or not 🙃

The gist of what I am trying to say is that the scope of react applications is such that in most cases any kind of state management works, but in some cases the boundaries are so constrained that only independent sources of global state makes sense. Otherwise you have to deal with bad tradeoffs, which is what you were talking about in the past couple of days on this channel.

Not just global state, but multiple SSOs

An example would help! (SSO = single source of ?)

state 🙂

I am working on a couple of demos, or rather, I made the repo for it and trying to setup cljs

I think that I agree with the multiple states idea - at least in the logical sense. A big form is probably only a part of a more complex app. There should be some documented interactions at the boundary, but the components inside the form should be concerned with the form-local state - to them it would be global though.

No, in our case the form is the whole app, it's served through Django. So it's not a single page app in any sense.

Example from how iOS/macOS does things - you instantiate a controller which encapsulates a view. You provide the controller with a few callbacks or a delegate object. You add the view to the visual hierarchy, the user interacts with the view, your callbacks get called. This in practice means a very clear boundary between state, events etc. I’m still not sure how this plays out in the web version.

Sure, an InputWhatever should be the controller of the state of the input value. But that's only the easy part of this problem. It's not enough to consider that only case. • it can be that InputWhatever might need to read state from another InputBhetever's value • or InputChetever might need to read the value of InputWhatever • or All of them need to read some remote state you have to fetch separately Traditional encapsulation from OOP would result in a terrible UX and a locked up user interface. (Sync mode in React) Or as they say, you would lift this state up, but suddenly, you have some inputs that don't control their own state, isn't that what you said should not happen?

I never said anything concrete, I usually just ask questions 😛

But an input field on its own is usually the wrong level of abstraction.

for what? 🙂

As usual in the web space , we are operating at a super low level of abstraction with limited primitives. Hence this Tower of Babel.

Input field is not what I was talking about. An InputWhatever could be a complex app that asks for several seperate piece of data.

it could be an input field, but that would usually not be enough

in fact, I believe that the problem is exactly the opposite web space yes but not low level primitives, I can just subscribe to keypress and keydown and similar things. Print, record video, etc. and not low level abstractions, unless you mean the communication layer where we are stuck with callbacks and promises, which I do admit are a bit too low level, I like queues

Would it ask for data , or should the data be provided to it? Does that data change during the lifetime of InputWhatever ? It’s hard to design things in the abstract :)

it's an UI Input component, so its business objective is represented by its name, which is to ask data from the USER with which it INTERFACES. It usually also has data provided to it from hardcoded and asynchronous sources, like auth and validation and generally feedback towards the USER 😉

I don't write either of those like 1% of the time

CSS is mostly generated or written by artists

Yeah, but you’re moving around the topic. I was asking about the whole shared state thing.

Yeah you’re in a different space than me then :)

I am sorry, I don't believe I am. The original comment from https://clojurians.slack.com/archives/C012GLC2SAZ/p1588407464326100 was a response to https://clojurians.slack.com/archives/C012GLC2SAZ/p1588407095317500 specifically where you say that > the components inside the form should be concerned with the form-local state - to them it would be global though. And I tried to highlight that component's own state (or form's own state in this case) being local only solves 1/4 of the possible scenarios and just the easiest of them. in this comment where you say I move around ;) https://clojurians.slack.com/archives/C012GLC2SAZ/p1588408068337600 I still talk about the same things, but from the Component's perspective. Sure all your own state appears global, but how do you share state between different React apps on the same page? That would be an "asynchronous source".

I am curious now 🙂 What space are you in?

An adjacent one that cares about CSS and visuals - and also frontend architecture 😉

Gotta go - I’m enjoying this conversation even though I think we need a shared vocabulary - or I need to stop trying to figure things out on my phone on a Saturday morning :)

It's a bit rude to insinuate that I don't, just because I claim that it's not big part of the complexity that stems from sharing state...