Fork me on GitHub
#om
<
2016-04-14
>
marianoguerra11:04:53

hi! is there a best practice or advice on how to handle error responses in the :send function?

marianoguerra11:04:20

particularly I want to handle 400s 401s and 500s and inform the user that something went wrong

cjmurphy21:04:16

What happens in a union query where some of the keys are the same? For example with this query say both have :id:

{:main (om/get-query MainTab) :settings (om/get-query SettingsTab)}
?

anmonteiro21:04:22

@cjmurphy: no problem there

anmonteiro21:04:40

in the Union queries tutorial all queries share attributes

cjmurphy21:04:14

Its kind of like inheritance?

cjmurphy21:04:20

I'm going off the untangled-demo that uses a union for tabs.

anmonteiro21:04:13

not sure what you mean “kind of like inheritance” simple_smile

cjmurphy21:04:15

There is a current-tab (i.e. map of props) that you then load into the 'super' (OO terminology) Tab which is generic.

cjmurphy21:04:01

(ui-tab current-tab)

anmonteiro21:04:46

there, all queries share :favorites

cjmurphy21:04:09

All the props are there (because it is a union) but only some of them are used (because not all the props passed in) depending on which tab the user is on.

cjmurphy21:04:45

It is a nice way of doing tabs:

(case type
        :main (ui-main-tab props)
        :settings (ui-settings-tab props)
        (dom/div nil "MISSING TAB"))

cjmurphy21:04:02

props are passed through with another jump. Hmm - sounds complicated but is not too hard when reading the code.

cjmurphy21:04:26

The unionized tab doesn't do any rendering (unless there's a missing tab). It sends the props thru to the one that is supposed to be rendered.

anmonteiro21:04:29

FWIW you can use simple hash-maps in place of case statements simple_smile

cjmurphy21:04:37

And theoretically you could do a select-keys as the props are being passed through, just to show (fwiw) that not all the props are needed in the particular case (say MainTab).