Fork me on GitHub
#fulcro
<
2017-08-14
>
cjmurphy07:08:53

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".

claudiu12:08:51

anyone using sablono or something else instead of om/dom ?

sundarj12:08:55

i've been using sablono, yeah

sundarj12:08:39

works great

claudiu12:08:40

@U61HA86AG any trouble with server side rendering ?

sundarj12:08:00

haven't got that far yet, sorry 😞

claudiu12:08:46

Any ideea if by using sablno we lose the "optimization" that om/dom enforces, by #js {} ?

sundarj12:08:56

not sure about the perf difference

sundarj12:08:42

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

claudiu12:08:57

🙂 giving ssr a try now. om/dom is really verbose, sablono looks a lite more nicer, curious if there any trade-offs 🙂

sundarj12:08:27

probably the perf isn't as great, up to you whether that matters more than ergonomics - certainly doesn't to me

wilkerlucio13:08:54

@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

claudiu13:08:06

@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 🙂

claudiu12:08:57

🙂 giving ssr a try now. om/dom is really verbose, sablono looks a lite more nicer, curious if there any trade-offs 🙂

tony.kay12:08:59

@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.

tony.kay12:08:11

I’ve not messed with alternate DOM libraries. I really don’t mind the direct DOM function calls.

tony.kay12:08:24

definitely adds some overhead, but I’d be surprised if the overhead hurts you that much.

claudiu13:08:07

@tony.kay But with the header approach from above, will the header query get the update route on route change ?

tony.kay13:08:59

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

tony.kay13:08:43

So, all-in-all, you’re probably better off with the link query

tony.kay13:08:40

I wouldn’t do the join, though

tony.kay13:08:55

just drop in the router’s ident. Current route will come in, just as an ident, which is all you need

tony.kay13:08:41

(query [this] [ [r/routers-table :page-router] ])

tony.kay13:08:58

then props will have that as a key, and the value will have :current-route as an ident

claudiu13:08:59

is it acceptable for two different components to have the same ident ?

wilkerlucio13:08:15

@claudiu yes, and that's is the point actually 🙂

tony.kay13:08:19

it is critical to the design

tony.kay13:08:24

what he said 🙂

wilkerlucio13:08:44

so you can have multiple views of the same entity, and they know how to sync and share data

tony.kay13:08:50

but those two will exist in the same spot in the db…you might have PersonView and PersonForm for example

claudiu13:08:03

agh 🙂 was thinking about conflicts with inital-app-state , and having to be carefull they don't update shared props

tony.kay13:08:16

they’ll merge

tony.kay13:08:41

so, you could technically do something weird if you give them two different meanings

tony.kay13:08:04

but if it is the same data, then they should have the same ident

claudiu13:08:15

ahh ok 🙂 Don't know why: having Article & ArticleThumb , seemed ok but Router & UserHead seemed a bit strange.

tony.kay13:08:32

Well, that is sorta strange.

tony.kay13:08:51

UserHead has it’s own separate state, that happens to need to know what router’s is

tony.kay13:08:04

so querying for router’s data via an ident makes more sense there, I think

tony.kay13:08:27

otherwise you’re breaking implementation abstractions a bit

claudiu13:08:51

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 ?

tony.kay13:08:19

if you used the same ident, yes, which could be problematic, if you accidentally use the same prop name for example

tony.kay13:08:26

I’d keep those two separate

tony.kay13:08:12

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

tony.kay13:08:22

I would not overlay the two by sharing an ident

claudiu13:08:15

cool 🙂 so referencing the router in UserHead, although more verbose seems like the best approach ?

tony.kay13:08:33

I think it is better design, in terms of keeping abstractions separate and reusable, yes

tony.kay13:08:25

router has a specfic single responsibility, and head has a different one that happens to have a data dependency

tony.kay13:08:35

and if you simplify your query a bit, it isn’t even that verbose

claudiu13:08:39

yep, can use the routing-table from fulcro.routing. It's pretty ok 🙂

tony.kay13:08:57

and you don’t need the subquery, just the ident

tony.kay13:08:17

you don’t need to recurse in via a link + join, you can grab the table entry itself with an ident

claudiu13:08:10

ok 🙂 will try that.

tony.kay13:08:59

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

claudiu13:08:56

Think I tried that, but did a join, since found it a bit strange that I had the props as {[:fulcro.client.routing.routers/by-id :page-router] {:current-route [...]}}

claudiu13:08:19

But if I have it as a variable, guess it does not matter that much 🙂

tony.kay15:08:44

yeah, you can just get the value you want…the key just looks strange