Clojurians Log v2
react
I am not very familiar with http/2 , so can you please help me out if it allows avoiding unnecessary roundtrips?
@ashnur you can avoid unnecessary connections. You can make several http requests simultaneously on the same tcp connection.
connection == roundtrip?
you need 1 roundtrip minimum for a cache check
I am not exactly sure what you're asking, but I think yes.
I don't think so 🙂 I can have lots of connections with no traffic, or a single connection with lots of traffic. HTTP2 can use less connections, but this will not reduce the amount of communication. It can also push resources proactively, which does reduce roundtrips, but I don't see how you will connect that to individual react components which will use a number of independent resources, some of which need to be checked anyway. I mean the "merging queries & graphs together" which you mentioned before http2. I think the fact that http2 reduces the number of connections is great because my wifi works usually better, but when I write a react component, this is not something I can use. Sounds like something which requires heavy custom work on the backend to work. I wish people would see the APIs I have to work with 🙂 Right now I am doing a form where I have to post to 1 api endpoint to create the place where i will save the form, that gives an id, then using this id I can post to another api which will save the data, then I can post to another api endpoint to upload files associated with the data, and then there is one another endpoint where I have to PUT the data with the id in a 4th format and special flag to "finalize" it.
Yeah, proactive push is the escape hatch in all this.
Mutations aren't in scope anyway :)
Well, I got a bit distracted by my own monologue, sorry : S
Proactive push is nice in theory, but very few stacks support it in practice (not just Clojure, even AWS load balancer doesn’t have it).
BTW regarding the whole state management stuff, I saw that the discussion here went quite heavily to the direction of managing remote data, with caches etc. While a big issue in modern web applications, it’s probably an orthogonal concern, with many different tradeoffs depending on the shape of the domain data.
Tearing is a Concurrent Mode thing
I have been using concurrent mode since 2016
So please take my previous question in light of that
This one? https://reactjs.org/docs/concurrent-mode-intro.html
yes
I wasn't aware that there are other ones?
I didn’t know it was available back in 2016 - that’s react 15 days.
It was part of Fiber, as unstable Async Mode
In fact, originally the whole point of it was to enable async mode, see here https://github.com/koba04/react-fiber-resources/tree/9d5216aebac45edd0b95f1a7c953caa1670617eb but there are so many people just abusing react's tolerance and backwards compatibility with its own bugs that even after 3+ years, this is still something people are mostly unaware of. At least people I keep contact with and do react daily.
What is telling that it was never a question that async mode 100% supports sync or legacy mode, the issue was always that as soon as any part of async rendering becomes default, it turns out that most people don't really write declarative interfaces, rather they put every controller, statemanagement code in event handlers or chains of promises, which likely have logic encoded as "When this happens, do this, after it succeeded do that, or if it failed do that, and after either of those, do that third thing and so forth" And then cometh async rendering with let's call every component twice by default 🙂
I’m almost thinking these days that perhaps the whole concept of state management should be thought completely orthogonally to React itself. The issue is mostly about managing complexity, naming conventions, encapsulating logic etc. React itself (I think) gives you these days enough primitives to be able to setup a reasonably performant way of changing the view when the state changes. From the naive “re-render the whole tree from the top, let the reconciler do the dirty work” to memoized components, to cursors/selectors that selectively trigger re-renders based on subsets of your state.
So if I would start a new application today, I would try to think first in domain terms -> what would an API that deals with my domain look like? The domain of course includes fetching data from the server, mutating data on the server, getting an answer back, waiting for an answer…
It's a browser? 🙂
Again, going back to stratified design -> dispatch an action is a low-level construct. The difference between (dispatch :fetch-more {:type :pages :number 20}) and (fetch-more controller :pages 20) is subtle but important — because the controller could be doing a whole bunch of stuff under the hood.
capturing rich media? opening and closing websockets?
If the websocket can be abstracted away (e.g. do you fall back to long-polling if websocket is not available?) then it’s an implementation detail.
I might be wrong. I would like to do an experiment to see if I can write the ‘business logic’ of an application without any UI whatsoever 😄
imagine a p2p chat program with permanent storage
something simple : P
https://github.com/omcljs/om/wiki/Quick-Start-(om.next) reading through this, it's quite interesting to look at the parser part. Literally just a function of state & query.
https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial also interesting.
I haven't read this material in a long time, it's interesting to reread with more experience.
https://github.com/omcljs/om/wiki/Queries-With-Unions looks like queries aren't built up automatically from children, I'll need to look at how apollo works to compare if that's automagical.
I'm confused, can anyone weigh in on whether apollo supports things like including the queries of your child? e.g. the child specifies that it needs [:name] and the parent decides it'll get it from [:favorite/dog], and merges into [:favorite/dog [:name]] through "magic"
https://www.apollographql.com/docs/react/data/fragments/ ah :) Manual like Om.