Clojurians Log v2

Idents are allowed, and that is what they mean: re-render the component

And yes, the built-in shouldComponentUpdate in Om elides any render if the data hasn’t changed

which is why your render functions should be pure

General note to the channel: Clojure recently renamed spec to clojure.spec.alpha. This affects the Untangled ecosystem because many of our macros use spec already. In the coming weeks I’ll be releasing code that will support this renaming, but for the time being you might want to stay on a clojure(script) version that hasn’t done that. Clojure alpha14 and cljs 1.9.473 are the current recommended versions.

@tony.kay while I get into untangled with your great videos, I also analyzed your developer tutorial online. I'm a little bit disappointed by the start performance of the app. Approx. 3sec until the first paint and 500k of gripped JS is really bold. Are their working examples of serverside rendering where I could look into that performance?

@danielgrosse I have not made any server-side rendering examples to date. Om Next is the underlying library, so you could look for examples there. Untangled works fine with SSR, however, you still have to wait for the JS to load…at which point I think a “loading” with a progress bar is easier, less maintenance, and just as good.

and the JS is cacheable, so next time use is fast

@danielgrosse we are implementing ssr with untangled

It is pretty doable

We have a certain use case why we are pursuing it, we need to render in iframes in a application where we want to show the information as fast as possible. If you have a SPA I wouldn't worry about it that much but it depends on the use case

That’s a good example of a good use case (^^^ you’re already logged in, and trying to embed something)

My start time for the tutorial on first load with my network speed (wireless broadband…not the fastest) is less that 1s (with cache disabled via chrome devtools). Once cached: less than 300ms.

The first paint does add about 1s to that, but it is a very heavy devcards app, so that isn’t really Untangled or Om Next, but devcards sorting through all of the cards and making the UI.

In the routing video you've created macros to simplify the defui syntax, were these only suitable for that usecase? IMO the syntax of defui is really repetitive.

It’s a lisp. Create macros to make the syntax you want. The defui syntax allows for clear extensibility of components.

it could be more concise, but the fact that it mimics protocol implementations of defrecord seems pretty good for general use-cases

In cases (like the union for routing) it certainly makes sense to make a more concise macro

because there is a clean pattern being repeated.

but defui is part of #om, and you will get no traction with D.N. on changing it.

but again…you can create whatever you want in syntax trivially.

and I don’t have much interest (personally) in “fixing” that part of the library. Everything else I can think of might be a little less typing, but at a cost in clarity. It’s not the thing that actually costs you much in software dev. It is superficial compared to the overall goals.

I didn't want to criticize DNs work. How the components are build is logical. I only wanted some ways to simplify repeating patterns. And you're right, it's doable with macros.

I think it is good to criticize everything 🙂

that’s how we improve

just saying I don’t see a general way to make that one much better

(defui Component :ident (fn [this props] ...) :should-component-update (fn [this props] ...) ...)

???

that’s just a few chars shorter, and doesn’t make it possible to extend easily (since you need method names)

it’s an exercise in preferences

Another question for my understanding. The defined routes are only necessary on the client side, as the client makes a query to the server at initialization based on that route?

I’ve generally used the term “route” to mean “a specific page in a webapp”. Is that how you’re using it?

server interaction is a completely orthogonal issue

you may or may not make a server request based on a page change, and you may or may not implement a page change using “ui routing”

the term routing is not my favorite 🙂

it refers to too many things

HTML5 routing is generally used to mean “tracking URI history for a page and making an SPA look like the pages correspond to different URIs, even though they are not loading from a server”

however, you could have SSR of each page so you can make a REST URL work “quickly”

for my SPAs I make the server always send the index page. The UI routing then takes care of rendering the right thing (this is on first page load)

The logic of the app decides when/what to load as data from the server

It I was going from page A to B and already had the data B needed: no server interaction at all

if I was loading B from a bookmark, then the app might need to load the data for B as part of that UI routing logic. Basically, the logic of “route to B” in the SPA would have conditional load based on “is B here?”

So, short answer: Yes: the UI routes are only defined on the client. UNLESS you’re trying to do SSR for each and every page, which then means you’d have a ton of logic on the server to properly pre-render those pages.

which leads back to my earlier comment on SSR being more of a pain than it is (generally) worth in an SPA.

Ok. Thank you for the answer.

Wondering if anybody has any suggestions for updating session in mutation. I can see that we can access the session through request in env but from looking at UntangledApiHandler looks as if parse-result is the only thing you can have control over (https://github.com/untangled-web/untangled-server/blob/ffeb37a328e5cfb300b34c984e81a699755c5995/src/untangled/server/core.clj#L195) Is there an idiomatic way for dealing with session manipulation?

In general you would put your session store in a component, and inject it into the parser

@kgxsz

then use the request to find the right entry and update it