GR is not high on the prio list right now. I’d take a PR for a fix. There’s a ton I’d love to be able to do to it, but it just isn’t economically viable for me to do right now.

Super super — I may take a swing at this later this week!

Hey, I have a fix — I’ll submit a PR for it later today. Woot!

cool 😄

https://github.com/fulcrologic/guardrails/pull/27

Hang on.. deleting this… submitting another PR with test cases for private and public.

Okay, added one more commit — good to go. Thx!

Released in 1.1.8

🎉🎉🎉 Thank you!!!

Not something that would pop in mind immediately. I guess it is quite an unusual requirement. do you have a realistic example?

I'm building a note-taking app. I want to sort notes by date, which necessitates including a date in the child data, which is only used by the parent doing the actual sorting.

I see. I would just include it in the child's query I think.

You don't have to use it in the child's rendering.

You could use the lambda form of :query and conj whatever you need to the child's query while preserving its metadata. But adding it to the child is simpler.

This is the general rule: The parent HAS to know about the child, but the child should not be coupled to knowledge of the parent. So, if the child has something the parent wants to see, it’s fine to look at the props for the children…in fact, the parent is the ONLY thing in this scenario that can possibly sort them because it is what has the children as a collection. It’s true that this introduces an implicit coupling, but the temptation to “modify a child” from the parent introduces stateful mutation into your system, which becomes much messier than just including the date in the child’s query manually and dealing with the fact that if someone removes it later then the parent won’t sort things. The former creates incidental complexity in the application. The latter results in an easy-to-find and easy-to-fix bug that rarely happens in practice, but has a low cost when it does. If you’re super paranoid, then you could add logging or even startup errors if the query of the child doesn’t include what you want…but I think that’s overkill. If you still disagree with the above, and really want to screw with the child query, then you can always use set-query! . That, combined with get-query could be used to modify the child query in the lifecycle of the parent. You’ll need to make sure that happens before your load needs to use the query, and of course you’ll want to make sure you preserve the original elements of the query.

Our depends where /how you use them. At like (or page 1) at the use site works fine. Or a init time mutation or initial-state...

> I still have to render my web pages by hand. What do you mean by that? On your other question: I think you mean when using a defsc-form ? If I'm not mistaken, it's the same as with every other normal fulcro prop, via :initial-state which will be merged here: https://github.com/fulcrologic/fulcro-rad/blob/develop/src/main/com/fulcrologic/rad/form.cljc#L815

Thanks guys! That's what I was looking for. What I meant by hand was I am not using the rendering plugin.

The book was updated recently to include much more detail on forms…please let me know if things are missing…better yet make a PR to help http://book.fulcrologic.com/RAD.html . The book source is in the main RAD repo

Hi @tony.kay. I am looking at the most updated book. I did not find out how to initialize props that are not attributes. I will make a PR when I figure this out. Setting :initial-state did not work.

So, forms may not have a way to do that. I don’t remember myself. With reports you can just send them as part of the route params. Let me look real quick…

Ah, there is no mechanism for it.

You’d have to augment the state machine

Forms are loaded/created at the ident of their ID, so they have no stable place in the db…thus :initial-state, while honored on first frame of app, will not work (it’ll end up at id nil)

Ok! Thanks @tony.kay. I will augment the state machine and make a PR to document.

it looks like it should work on create, but it won’t work on load, so I guess that’s a bit of an inconsistency

ah crap I've mixed up the lines in fulcro inspect. it's at nil indeed. Sorry for the confusion @UGNMGFJG3

but that’s only if you send the initial-state key with the event (which can be done in route params or form/create!. E.g. (rroute/route-to! Form id {:initial-state {:ui/boo 42})

where id is a tempid

really, that will work only by accident. It was never really meant for initializing additional props on the component itself…which is an oversight. You can always use component local state with :initLocalState if it’s a trivial bit of ui stuff.

I’m thinking that since I allow query-inclusions, I should probably have a standard way to get initial values into those when they aren’t actually part of the form data (which they will never be).

I’d say: I’d accept a PR to allow :initial-state on edit/view/create in extra params. For the non-create ones, that stuff would probably need to be pushed into the generated pre-merge to go into the tree so that you could add things to children as well…Hm, but that doesn’t really solve it. I think I didn’t do this because the only fully general way to handle this is to expand the state machine…for example, adding a new child is an event, and that initial pre-merge is only applied to the top-level form.

let me think on it…I think there’s a good generalization possible that should probably be an option.

I am going to use init local state for now. I will probably have to amend the UISM for other parts of my project.

I’m adding an initialize-ui-props option. Just makes sense when there’s query inclusions

1.1.0-RC7

initialize-ui-props

now that was fast 😄

None of this is very complicated 🙂 it was a very small patch: https://github.com/fulcrologic/fulcro-rad/commit/e0f9402f13e1c270c40bd171288a328396420b74?diff=split The new docstring is probably longer than the actual new code.

Thanks @tony.kay! That helps me a lot! i’m sure others will benefit too.

It’s usually much harder to make the decision about what to include than it is to include it 😛 So, once I’m clear that something should be included it’s best to just do it, lest I forget my reasoning and have to do the “thinking about it” part all over again