Clojurians Log v2

@lilactown sounds like apollo or fulcro. What differences from those solutions do you think would be useful?

https://medium.com/@mtiller/encapsulating-application-logic-with-reactors-392635763e7 maybe related

I think having multiple “stores” makes sense if your application is highly modular. (More like a set of mini-applications that share a few top-level stuff like current user etc).

In redux world they deal with this with “slices” which afaict is just a naming convention. Even though redux allows you to have multiple stores...

You can also solve this by giving each area a derivation of the root, and giving them a namespaced key.

It's a useful thing to enforce though..

https://www.apollographql.com/docs/react/why-apollo/ this looks vaguely usable from clojure script

Apparently I'm preaching to the choir... https://clojureverse.org/t/example-apollo-graphql-integration-with-react-cljs/4223/5 So you'll definitely need to tell me why not just use apollo :)

The compile time requirements are annoying. Needing to parse graphql queries etc. The fallback is to do it at runtime but then your bundle size explodes.

Also - you will be dealing with JS data structures, right?

Yeah, which I hate, buuut, for network requests js->clj is not terrible.

Oh sure - but then you can’t put the result in Apollo. The main benefit of Apollo is the cache.

Oh, hmm. It would be nice if it didn't care about the store.

Just data in, data out operation.

I loved using Apollo at my last job

Problem is we’re not using graphql at my new gig

Might be difficult to adopt, and we lose some of the e2e clojure benefits we have: namespaced keywords, transit

Also the type system

Apollo includes also a graphql resolver implementation, will rewrite your queries, answer parts of them from the cache etc. I just find this way too much :)

So, in terms of servers. There's 3 big forms that come to mind: - REST - gql - pathom/eql Do we think that the specification of the data you want should be tied to the underlying format or independent? I'm thinking tied to it.

I guess what we want the library to do is: Take old data, and query, and shrink it down to the minimum query required for the data? How do caches get invalidated in an apollo world? Manually? Or do they naturally update in response to mutations or something?

triggering a fetch or mutation in apollo typically invalidates the cache, though you can control that behavior

typically what happens is:

query in render
 -> check cache
   -> is cached? render immediately unless configured to always fetch
   -> is not cached? fetch and return a loading state
 -> subscribe to changes in cache

dispatch fetch
 -> start request
   -> notify any subscribers that want to know when data is loading
 -> request returns, populate cache
 -> notify any subscribers that data has changed

dispatch mutation
 -> start request
   -> if configured, optimistically update cache
 -> request returns
   -> if configured, update cache with returned data; GOTO last step of dispatch fetch
   -> if configured, begin fetching a query to update the cache; GOTO dispatch fetch

So the other part of it is merging queries & graphs together. I wonder if that even matters now we have http/2

https://hackernoon.com/non-event-driven-redux-5ce56776184f this is a question I have.