Clojurians Log v2
fulcro
@tony.kay yes
the subform's data prop is in the :form-fields set
if I edit the subform then edit the parent form and then do a diff from the parent form, it works
are you using set…!! ?
(double exclaim) or sync txns?
those do targeted renders to just the component in question. Shoot, that is trickier than I intended it to be when I added those. Use the single ! variants. The behavior really depends on which rendering strategy you’ve chosen (if you override the default) and if you use !!
I'm not sure what you're referring to with the double !!
I'm using functions like set-value!
It looks like the issue I was having in Fulcro 3.0.9 is fixed by 3.4.3.
I’ve created a datomic only port of the rad demo with 3.4.3 fulcro and integrant rather than mount. Everything works perfectly as expected, except I get this error (from the console) when I hard refresh on a path e.g (http://localhost:3000/accounts?_rp_=WyJeICJd&_). I don’t get the error with the Fulcro version from rad demo 3.2.17.
ERROR [com.fulcrologic.fulcro.routing.dynamic-routing:188] - dr/target-ready! was called but there was no router waiting for the target listed: [:com.fulcrologic.rad.report/id :ventures.fierce.rad.ui.account-forms/AccountList] This could mean you sent one ident, and indicated ready on another.If I route using the links it works fine.
The error only occurs > 3.4.1
I am doing this more and more and I am not sure if this is the right thing to do or an anti-pattern.
I often have components which displays a static set of things (eg. a header) as well as a dynamic set of things (eg. a panel selected amongst other).
Keeping all data at the level of such a component, as opposed to splitting it across children, is often easier to handle and definitely keeps the cleanup logic simple when the component is discarded.
My simple solution is to do a union on a prop specifying the dynamic thing (eg. which panel is selected). However, that dynamic thing is created on the spot in the DB (eg. when the panel is selected, dissoc'ed when unselected) and has only one prop: the ident of that parent component. When writing defsc for a given panel, it is then easy to fetch whatever props are needed from the master component. It works all right, but something feels off... Should it?
Essentially, it does a union on itself, so to say (hopefully I am clear)
I have two components that have a different set of parents, sharing only the root. I need to share some data between them through a series of steps. Is a state machine a good option in such a case? The other option I can think of is storing some data in the root. Not sure which one is abuse of the system and which one is the better approach.
@cjmurphy I'm trying to make sense of you suggestions but it's not totally clear to me. I think I have some misunderstandings about the way components and their queries compose together.
To describe my problem more, what I have is a Note , which queries :note/text and a CardList. The CardList queries just a :card-list/cards, and each Card has :card/text, which I need to be the same as the :note/text. The issues is that Note is not a parent of CardList, so I can't use a callback to grab the :note/text.
> Could they both have the same join? By that I mean join to either the same component or different components that have the same ident. That way they both get exactly the same entity (for that join) in the props. Another thing you could look at is link queries.
So join the Card to the Note, while the Note queries for Card's parent, CardList? Am I understanding correctly?
> You can repeat the same data all over your UI as much as you want.
Isn't this what "side-banding" data is about, and is advised against in the docs?
> All the steps needing to be done to the data could just be a mutation??
Ultimately, yes, but isn't the point of the SM to make things more simple when there are mutations that are connected through a series of events?
I would just have :note/text, no need for :card/text. Do you need a Note table/entity/component? Put :note/text in the Card component.
A Note will have many Cards, and the :note/text should contain the original text, while Cards may have modified versions of the text from the Note they were created from.
@cjmurphy So the :card/text starts off as a copy of the :note/text, but it can be modified and should be diff-able against the original :note/text. That's why I chose to duplicate the text in the first place.
So :note/text and :note/text-archives. Two attributes that could perhaps go into the same entity/component??
Where :note/text would always be the current text and :note/text-archives would be previous versions? Need to think about that a little, might be a possibility. The other consideration is that the original text and the current text need to be displayed in entirely different parts of the UI. I guess I could create two components that work off the same entity to achieve that?
I was I guess just saying that it is quite idiomatic in Fulcro to have repeats in the tree that is your UI. If what you want to pull in is a singleton (component/id) then you can do it with initial-state. And for these relationships that form after start-up then the same thing can be achieved using a mutation.
Yes two components that work off the same entity (so same ident) sounds good.
With all that considered, to my novice mind it still seems like a state machine would be helpful in passing data around disparate components. Is that correct? Is there a reason you seem to be advising against using a SM here?
But it could also be the same component, repeated again, so joined into a different component. component just gives the 'look' obviously. You might want the same appearance and the same data twice in the tree. Or you may want same data and different appearance. In both cases the join component will have the same ident.
Yeah wasn't advising against it. I'm no great expert on knowing when to use one or not. We all have to try using them and build up our intuition for them is all I can say there 😜
Perhaps if you can already see the actors and states then its a good idea to go for it...
Thanks. Appreciate your input very much. I feel a little stuck on this part right now, going to work on another portion of the app for a while and then return to this a bit later, maybe restructuring my components a little bit. I've studied the EQL portions of the documentation and the EQL spec itself and know it pretty well, but putting it into practice is not intuitive for me just yet. Guess reading the docs can only get you so far, and getting your hands dirty is where the real learning happens.
This https://clojurians.slack.com/archives/C68M60S4F/p1604836869080100 may be helpful
@randumbo Could they both have the same join? By that I mean join to either the same component or different components that have the same ident. That way they both get exactly the same entity (for that join) in the props. Another thing you could look at is link queries.
Think I better return to this tomorrow morning with a fresh brain. Thanks for the input guys, I'll explore those options.