Fork me on GitHub
#untangled
<
2017-05-24
>
mitchelkuijpers15:05:28

So I am looking at untangled-ui is it safe to use the form support? Because I need get some forms done and I like how it works

mitchelkuijpers15:05:44

I already have it working with this component: https://atlaskit.atlassian.com/components/field-text loving how it works so far

fz15:05:07

Wrapping my head around union queries — I'm picturing two "modes" of tabbed interfaces: • Scenario A: Data for each tab is assumed "independent"; they can coexist in the database either up-front or as the user navigates between tabs • Scenario B: Tabs are mutually exclusive (radio-button semantics), where each tab loads a different query but loading one means the other is "inactive"/"invalid" Am I correct in thinking that union queries only apply in the former case? Concrete example: Suppose I'm at a subtree in my database. The data here can either look like {:due-date {:date #inst 'foo}} or {:due-date {:vague :later-today}}. If the data (loaded from server) looks like the former, I'd render a date picker. Otherwise, if the data looks like the latter, I'd render a <select>. In this case, I'd use regular conditional logic rather than a union query?

gardnervickers15:05:22

@fz No union queries apply to both cases

fz15:05:56

Ok — in all the examples there is some sort of :tab-type field in the initial state of the tab components which is used to power the union ident. In this case, I'd drive that ident by inspecting the subtree fields, right?

gardnervickers15:05:21

No the :tab-type field would be derived for you during normalization. In your union ident you'd specify something like [(:tab-type props) (:id props)]

gardnervickers15:05:49

Then in your render method, you'd dispatch on (:tab-type props).

gardnervickers15:05:02

Not sure what you mean by the subtree fields.

gardnervickers15:05:35

Not sure where in the tree you're talking about is all 😄

fz15:05:37

That makes sense. But in this case, how would the value of :tab-type get set in the first place? Concrete example: Suppose I'm at a subtree in my database. The data here (loaded from server) can either look like {:due-date {:date #inst 'foo}} or {:due-date {:vague :later-today}}. If the data here looks like the first case, then :tab-type would be :specific. Otherwise, :tab-type would be :vague.

fz15:05:59

More broadly, in this scenario, :tab-type is "determined" by the shape of the data, not the initial UI state

gardnervickers15:05:14

So for your specific example, you'd have something like {:due-date-type :date :date #inst} and {:due-date-type :vague ...}

fz15:05:04

Ah, so I'd have to be explicit about the type, rather than implicitly deriving it

gardnervickers15:05:04

Then (assuming there's an id field there too), your ident would be [(:due-date-type props) (:id props)]

gardnervickers15:05:47

I mean you can totally derive it using the (om/ident) function

gardnervickers15:05:54

I wouldn't as it adds some confusion

gardnervickers15:05:49

Plus you'll have to derive it all over the place, in your mutations, in your render function, etc..

gardnervickers15:05:57

Much easier to derive once and just stick it into the app state.

fz15:05:26

Good call, thanks

tony.kay17:05:52

@mitchelkuijpers safe is a relative term 😉

tony.kay17:05:11

it should be relatively stable, if that’s what you mean.

mitchelkuijpers17:05:22

@tony.kay that was what I meant 😉

mitchelkuijpers17:05:20

That's good news

baris18:05:13

@mitchelkuijpers I started again with my untangled project yesterday and I’m using the untangled-ui components and the forms support. So far I’m very happy with that.