Fork me on GitHub
#re-frame
<
2019-01-29
>
ivermac15:01:09

Hey everyone, I have a couple questions . Has any of you needed to perform some logic on the view file (where you write your hiccup-like markup)? I'm trying to render a table but I'd like to show some links on the table based on some logical conditions i.e. my row data has to meet a certain criteria for a link to show on that row. Where's the best place add this logic, is it on my view file, subs file or events file? Or should I create a utility file, add my logic function there then require it in my view? Thanks

samedhi15:01:38

@mark.ekisa_slack_cloj I would keep all rendering logic that isn't stateful changing in the subs. Logic that changes the state of your app-db should go in events. Try to keep the rendering logic (your view file) as simple as possible, ideally just taking a map (or seq of maps) and rendering. Personal call, but I only put things that are not dependent on app-db in in utils (examples are a little thinger to highlight every other line per row in a table; it alternates highliting, but it doesen't actually depend on the value of each row (although I guess, pedantically, it does depend on the number of rows 🙂 )).

ivermac15:01:53

Cool, thanks @samedhi! That's helpful.

escherize16:01:38

I have a riddle for you guys! A friend of mine is moving from a rum app with (an 'interesting' home-rolled state mechanism) over to re-frame (and thus reagent). So, they want to have a reagent component inside of a rum component tree. I came up with a solution but I'm not sure if it's good, or if there's a better one. Can any of you think of a good way to do it?

escherize16:01:52

should I have posted this in #reagent?

lilactown16:01:37

#reagent probably would be better, but I think the simple answer is to just treat it like a generic React component