Clojurians Log v2

Yeah, I got very excited when I saw the raw demo :) I've been trying to figure out what I can build to demo how qlkit would fit into our platform.

Hello, Do you plan to support react-native?

@sichirc certainly we'd like to support react-native, but we're bandwidth constrained-

unlikely to happen soon (at least as a project internal to our company)

can I open a pr that adds support for re-natal integration?

@sichirc absolutely 🙂

@sichirc How much is involved in getting integrated with re-natal? (I'm curious)

I was reading the announcement on Medium and I'm not sure I understand this correctly. Is it saying everything re-renders on every change? If that's the case, why use react?

Also, can we expect a totally awesome music video for this in the future? 😄 (not serious here, but the one for your book was totally awesome 😄 )

defcomponent macro creates react class with implemented shouldComponentUpdate method

@dominicm I'm one

@bmaddy React still does the diffing, om.next etc, just do additional efforts in this area.

@sichirc Sorry, I was unclear when I asked. What kind of changes are required to make it happen?

sorry for the misunderstanding, right now qlkit has function refresh, this function call reactDOM.render, this function is called in different places in code

@bmaddy Yes, diffing is still happening on several different levels, we rely on react to optimize the rendering. However, OmNext goes BEYOND vanilla react to optimize rendering- Qlkit doesn't take those additional steps, but still optimizes rendering like any react app.

I will clarify this in the medium article

@sichirc Is supporting react native as simple as swapping that function call for:

(if (react-native?)
  js/reactNativeDOM.render
  reactDOM.render)

in react native we don't have render function, we need to register component in app registry, and do it only one time when up starting

@dominicm unfortunately I haven't played with react-native so far and can't contribute to these sorts of questions (yet)

@sichirc uploaded a file: https://clojurians.slack.com/files/U8ZCX3J9W/F90TE65K5/-.clj

I was told that om.next would be very difficult to translate to GraphQL, I'm looking at what qlkit's query language is like, and it seems like it would be viable to hook this up!

Although, the clj backend seems stateful, with atoms and such. Which doesn't seem like it would work with the reloaded workflow for the server.

@dominicm well, the backend in the demo app was just designed as a quick demonstration- the expectation is that you'd replace the atoms with datomic or some other database for a more substantial app.

The part of the server that's important in these types of query language systems are the parsers, but where those parsers put the data is flexible based on the needs of the app.

@drcode does ql/mount have no impact on how ql/parse works? (In clj)

I think you're referring to ql/parse-query (there is no ql/parse)- The parsers defined in ql/mount will determine what parsing methods are called by ql/parse-query

qlkit assumes that there is only one set of parsers on the client, and one set on the server- These are globally defined by calling mount. This differs from OmNext where you can have multiple sets of parsers on client or server (but at the cost of complexity in terms of how the parser for a parent query term triggers the parser for child query terms)

(also, it means you can't mount more than one root qlkit component into the dom, which we consider acceptable as mounting multiple completely independent root components is an uncommon requirement, and you can still work around this with advanced-compiled clojurescript)

This seems particularly difficult for having apps which service distinct clients. It seems that if the state was passed around explicitly, then library users can manage the state as required

are you saying that you want a separate state for each client the server services? I guess what would make more sense to me is that each client has some sort of ID (session ID, userid, etc) and then the server stores info about all clients in a single place (database, atom, etc) but just associated with a specific user's id.

Then the question is just "how do the parsers know what the current user is that's being serviced?" and we have a precise mechanism for that: The root parser on the server does something like (assoc env :user-id id) when it calls parse-children (as in the demo example with todo-id) and then all the children have access to the current user identifier.