This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-19
Channels
- # ai (3)
- # aws (1)
- # beginners (94)
- # boot (26)
- # cider (3)
- # cljs-dev (99)
- # cljsrn (86)
- # clojure (263)
- # clojure-dusseldorf (4)
- # clojure-greece (22)
- # clojure-italy (2)
- # clojure-quebec (1)
- # clojure-russia (12)
- # clojure-spec (71)
- # clojure-uk (123)
- # clojurescript (92)
- # core-async (4)
- # cursive (13)
- # data-science (2)
- # datomic (123)
- # docker (2)
- # emacs (15)
- # events (1)
- # graphql (2)
- # hoplon (71)
- # jobs-discuss (7)
- # lumo (5)
- # off-topic (12)
- # om (6)
- # onyx (97)
- # other-languages (4)
- # overtone (2)
- # pedestal (1)
- # re-frame (20)
- # reagent (33)
- # remote-jobs (1)
- # ring-swagger (1)
- # rum (5)
- # slack-help (6)
- # uncomplicate (1)
- # unrepl (33)
- # untangled (48)
- # vim (23)
- # yada (21)
And yes, the built-in shouldComponentUpdate in Om elides any render if the data hasn’t changed
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.
@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
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.
(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)
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?
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”
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”
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)
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?