Clojurians Log v2

@currentoor sorry, I meant url routing. I think I saw somewhere someone solving on the parser (query would return something conditionally on current route for ex) rather than using union queries on top component. still digging into design patterns here, still unsure on best way to go for current proj with cljs+react. I thought about implementing UntangledApplication, to better underestand Om.next first

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

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

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?

@fz No union queries apply to both cases

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?

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)]

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

Not sure what you mean by the subtree fields.

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

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.

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

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

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

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

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

I wouldn't as it adds some confusion

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

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

Good call, thanks

@mitchelkuijpers safe is a relative term 😉

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

@tony.kay that was what I meant 😉

That's good news

@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.