Fork me on GitHub
#untangled
<
2017-03-31
>
claudiu04:03:27

adding :top-router to (om/transact! comp-or-reconciler… seems to do the trick.

urbank13:03:39

Do I understand the idea of the forms portion of the untangled-ui library correctly? Basically, a form targets some entity in the app-db, so that values entered into the form component are committed to that entity

mitchelkuijpers15:03:34

We laughed our asses off

urbank15:03:21

So perhaps I'm abusing initialAppState

urbank15:03:02

I have a defui component without render that declares the query, ident and initialAppState for an entity in the app-db

urbank15:03:08

Then there are supposed to be a bunch of other components which are forms that edit entities of this type

urbank16:03:45

Ok... so it was my error that it wasn't working. Called the wrong query. Still, did I stumble upon the correct solution. If I want to initialize an entity in the initial state, that multiple components will render and edit, I declare it's query, ident and initial-state in a defui

urbank16:03:14

then I use them in the components that are supposed to edit this entity

urbank16:03:49

I compose its initial state and query into their initial states and queries. To make it all the same entity, I give the Entity component a default id, so that get-initial-state always yields the same entity, even if called on many components

tony.kay22:03:16

Yes, the form keeps an alternate state for the entity. When you commit it, it copies it over. It also supports sending the delta remotely

tony.kay22:03:25

look in the devcards for it...the docs are close to good 🙂

tony.kay22:03:04

@mitchelkuijpers @fatihict Glad you guys enjoyed it. If you haven't seen "The Doctor" Kids in the Hall sketch, you should watch it...it's kinda older, and no one got that one at all

fatihict12:04:51

Ahhh, now I see. I didn't get that one either, but that's hilarious 😃. Also the ending about the cake was cruel 🍰😆

urbank22:03:52

@tony.kay The guide cleared up a lot... there's still a question forming, but it isn't quite ready 🙂

urbank22:03:50

@tony.kay I think there's a small error in the guide.

urbank22:03:04

(f/form-field my-form :name) --- outputs ---> (dom/input #js { ... }) should be

urbank22:03:16

(f/form-field comp my-form :name) --- outputs ---> (dom/input #js { ... })

urbank22:03:17

when calling f/form-field is it possible to specify attributes of the resulting input? For instance, to add a call to commit onBlur? I see that I can pass things like :className to f/text-input in IForm, but is there a way to do it dynamically?

urbank22:03:32

Hm... for some reason commit-to-entity! isn't updating the target entity

urbank23:03:13

Yes, so apparently the entity ended up in the database because the other view in the join query didn't yet implement form. So a component with just a form did not even create the actual entity that the form was supposed to augment. So I must be missing something.

urbank23:03:42

All the examples in the guide some to be such that entity IS the form... so where is it committing if there isn't an unaugmented version of the entity in the app-db?

urbank23:03:47

In my case I have a type of Entity which is a defui that just declared initial-state, query and ident. Then there are a bunch of forms which all edit this entity same entity. However, the entity doesn't end up in the initial state, because it isn't directly used in a Query

urbank23:03:37

But rather:

urbank23:03:21

So I see why Entity doesn't end up in the database... but what do I do so that it will? started-callback? Entity doesn't really have 1 representation in the ui, but multiple views which edit it.