This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-14
Channels
- # aws (1)
- # beginners (52)
- # boot (1)
- # cider (9)
- # clara (4)
- # cljs-dev (40)
- # cljsrn (2)
- # clojure (166)
- # clojure-dusseldorf (1)
- # clojure-italy (38)
- # clojure-spec (13)
- # clojure-uk (32)
- # clojurescript (337)
- # cursive (11)
- # data-science (47)
- # datomic (11)
- # emacs (3)
- # events (1)
- # fulcro (57)
- # hoplon (16)
- # jobs-discuss (1)
- # juxt (11)
- # keechma (21)
- # mount (2)
- # off-topic (44)
- # onyx (9)
- # re-frame (33)
- # reagent (1)
- # ring-swagger (3)
- # specter (2)
- # test-check (37)
- # vim (30)
Regarding forms, I have noticed that removing a detail from a master (e.g. phone from person) does not result in the master becoming dirty?
. I just want to verify that this is expected behavior. It accords with the documentation: "Checks if the top-level form, or any of the subforms, are dirty. NOTE: Forms remain dirty as long as they have tempids".
@U61HA86AG any trouble with server side rendering ?
Any ideea if by using sablno we lose the "optimization" that om/dom enforces, by #js {}
?
looks like this is what it uses to do the conversion: https://github.com/r0man/sablono/blob/master/src/sablono/compiler.clj#L282
as for SSR, the server namespace just uses React's methods, so should be the same as om.dom: https://github.com/r0man/sablono/blob/master/src/sablono/server.cljs
🙂 giving ssr a try now. om/dom is really verbose, sablono looks a lite more nicer, curious if there any trade-offs 🙂
probably the perf isn't as great, up to you whether that matters more than ergonomics - certainly doesn't to me
@claudiu I don't think om/dom is verbose, ok you have to deal with the js stuff, but besides that I prefer it than having an overhead with an extra library, but that's really a preference matter I think
@U066U8JQJ Yep. Guess it's just a matter of preference, could refer div, p. a I guess, don't know if that's a good idea, Sablono server side rendering seems to be in the open issues list, getting some strange errors. Will leave it for now, maybe om/dom grows on me 🙂
🙂 giving ssr a try now. om/dom is really verbose, sablono looks a lite more nicer, curious if there any trade-offs 🙂
@claudiu on the current-route question: It just hit me that I told you something incorrect. You cannot put an ident in InitialAppState if you also add it to the query…what you want to do is compose the router into the Header with its initial state. This sounds like duplication, but it isn’t because of normalization:
(defui Header
static fc/InitialAppState
(initial-state [c p] {:router (fc/get-initial-state TheRouter) ...})
static om/IQuery
(query [this] [{:router (om/get-query TheRouter)} ...])
...)
Then also compose the router in normally where you use it for actual routing. Now, technically this will give you the full depth of the routers data (recursively), but Header need not render that.
If you want to lighten the load, then make a RouterInfo component that has the ident function of routers, but only queries for :current-route
, and make its initial state return just enough data (the id of the router) to properly normalize. Normalization of entities is done through merge, so it shouldn’t hurt to normalize a smaller amount of data over top the real router at startup.I’ve not messed with alternate DOM libraries. I really don’t mind the direct DOM function calls.
definitely adds some overhead, but I’d be surprised if the overhead hurts you that much.
@tony.kay But with the header approach from above, will the header query get the update route on route change ?
Ah, when you transact the route change, the follow-on read would have to name :router
. Technically the nested router would see the router change, but Om could skip header and update the router directly. The follow-on read would force it to do the Header subtree
just drop in the router’s ident. Current route will come in, just as an ident, which is all you need
then props will have that as a key, and the value will have :current-route as an ident
@claudiu yes, and that's is the point actually 🙂
so you can have multiple views of the same entity, and they know how to sync and share data
but those two will exist in the same spot in the db…you might have PersonView and PersonForm for example
agh 🙂 was thinking about conflicts with inital-app-state , and having to be carefull they don't update shared props
so, you could technically do something weird if you give them two different meanings
ahh ok 🙂 Don't know why: having Article & ArticleThumb , seemed ok but Router & UserHead seemed a bit strange.
UserHead has it’s own separate state, that happens to need to know what router’s is
but that also means that if later on I want to have UserHead data it will be in the same place with router data right ?
if you used the same ident, yes, which could be problematic, if you accidentally use the same prop name for example
One’s job is to map where you are to a UI indicator. The other is to actually swap out UI based on where you are. The shared piece of interest is :current-route, which one should own, and the other query
cool 🙂 so referencing the router in UserHead, although more verbose seems like the best approach ?
I think it is better design, in terms of keeping abstractions separate and reusable, yes
router has a specfic single responsibility, and head has a different one that happens to have a data dependency
you don’t need to recurse in via a link + join, you can grab the table entry itself with an ident
k. And the ident query is very efficient. Just gets the ref to the table entry. The link + join + subquery requires a bit more processing. Kind of not intuitive cause you actually end up with more data with the ident query, but it costs less to do so