Fork me on GitHub
#fulcro
<
2020-03-02
>
holyjak11:03:26

<@U0CKQ19AQ> Does it make sense for `dr/route-immediate / dr/route-deferred` to ever use different ident than the one of the component in whose `:will-enter` they are used? If they always use the ident of the component they are nested under, would it make sense to log a warning when those two do not match? I'd be happy to try to make a PR for it. (I guess that we could set a dynamic var `*ident*` to `(get-ident class {})` which would return `[:some/id nil]` and then use it inside the route-* functions to check that `(= (first ident) (first *ident*))` (and perhaps also compare seconds, if not nil)? If sending empty props is too hackish, we could modify `build-ident` to add metadata to the ident functions such as `{::ident-table &lt;kwd&gt;}` for keyword and template idents and check at least these two, in there is no good way to check a method ident.)

tony.kay15:03:17

@holyjak You are welcome to try, but I’m not sure you’ll be able to know the correct props. A component with an ident derived from props has no specific tie to those props until it’s mounted, and it never will be mounted if you don’t give it the right ident to mount.

holyjak15:03:31

True, that's why I would send in empty props. I don't really care about the dynamic part of the ident for there is no way to check that, only the table name matters (the second element of the ident vector matters and can be checked if it is static). So (get-ident class {}) would be usable, no?

tony.kay15:03:18

yes, and if you want to avoid the warning that will give, use comp/ident instead.

tony.kay15:03:58

get-ident just adds the error checks

tony.kay15:03:14

sorry, I didn’t read your text fully. and yes, a PR that adds useful debug messages is great.

👍 1
tony.kay15:03:41

Oh, and there is another sanity check you could do. You do know where the thing is supposed to be, so you could pull the map of data from there and pass it to ident and see if it returns the full thing. If you did that on target-ready (since they may not be there until then) then you could indicate something about the props not being as expected.

👀 1
holyjak17:03:40

☝️ you mean in addition or instead of the checks in route-deferred/immediate? It is better because it can see the props but it I assume does not know whether it has been defined inside :will-enterand that it indeed was defined inside route-deferred/immediate?

holyjak17:03:46

Here is a proof of concept https://github.com/fulcrologic/fulcro/pull/377 Any early feedback? I also need to look into the check in target-ready.

holyjak20:03:27

@tony.kay I am unsure how to do what you propose. In target-ready I have indeed the expected target ident but how to verify that it actually corresponds to some mounted component (which what you proposed, I believe)? Where to get the props for comp/ident? But I can verify that (not (nil? (comp/ident->any app target))) ?

tony.kay20:03:46

you can get the state-map from the app, and the props from that via the proposed ident, no?

tony.kay20:03:07

(get-in (app/current-state app) target) is the props. Pass that to (comp/ident class props) and see if you get back the target ident

tony.kay20:03:40

if not, they gave you an ident that didn’t resolve to data that can possibly generate that ident, meaning something is wrong

holyjak20:03:11

ok, didn't know the state map can give me the props, thx!

tony.kay21:03:24

it’s shallow, right? It’s the normalized db, so get-in gives you the normalized component, but ID is always in that, by definition

tony.kay21:03:36

so you wouldn’t use that to render, but ok for getting ident

holyjak21:03:13

OMG, of course. I am still getting used to Fulcro :-)

tony.kay21:03:02

yep…it’s funny, as you go this kind of thing will happen to you a lot: you’ll think the thing you want to do is going to be hard, then you’ll get in there and go “Oh, right, I have this and that, and the data is normalized…done”

❤️ 1
holyjak18:03:24

@tony.kay I have updated the PR, please let me know whether you have any further comments, when you have time. Thank you!

gibb20:03:02

I love this project. Staggering education / documentation effort!

fulcro 12
tony.kay21:03:59

It looks like the Chrome extensions store accepted the new version of Inspect. This means the db explorer should be available generally now!

tony.kay21:03:38

The DB Explorer is a tab right next to the DB tab. It is much more navigable (and search is instant). You can search by IDs or values, and idents are clickable links.

tony.kay21:03:22

It’s been available in the Electron release for a while, and I’ve found it to be super useful on my larger projects. The old db tab is simply too slow because it has to render the entire db.

🎉 15