re-frame 2023-11-06 | Slack Archive

Kimo16:11:28

Flows have http://day8.github.io/re-frame/Flows/#dedicated-inputs. Should we do it that way? Does that explanation make sense? We're considering whether to: Delete the top-level :inputs key, keeping only the dedicated inputs. That means you always declare separate inputs alongside the individual :live? and :output functions. Pros: • Flows can be true literals, without needing a https://github.com/day8/re-frame/blob/a03e8a39498f6934cc54361fda6e9dc5012114aa/src/re_frame/flow/alpha.cljc#L44. • There's only one way of doing things, no ambiguity. • The design parti of https://github.com/day8/re-frame/blob/a03e8a39498f6934cc54361fda6e9dc5012114aa/src/re_frame/flow/alpha.cljc#L120 vs. https://github.com/day8/re-frame/blob/a03e8a39498f6934cc54361fda6e9dc5012114aa/src/re_frame/flow/alpha.cljc#L121 is front & center. Cons: • A double-nested map makes our DSL feel awkward. • Harder to drip-feed concepts in the https://day8.github.io/re-frame/Flows. • Harder to talk about inputs. Technically they're the output-inputs and the live-inputs. Don't have dedicated inputs. We're somewhat resolved to keep them, though. Pros: • One way of doing things. • Simple, flat DSL • Fits clojure's philosophy of permissive maps. If you don't need an input, just don't destructure it. Cons: • Dirtiness & bardo are coupled. (christian buddhism?) • You might not need all the inputs for both :live? and :output Actually have both dedicated & top-level inputs. That means we merge top-level :inputs into dedicated inputs at runtime. Pros: • Simple case is easy to explain. • The flow you register is the actual map you type in. Cons: • Two flows could be logically equivalent. Procons: • One way of doing multiple things...? Keep things as they are. Best of both worlds...? Pros: • Technically one way of doing things, though it looks like two. Cons: • The flow you register isn't really the map you typed in. The real flow gets constructed when you call reg-flow.

p-himik16:11:01

Personally, I'd go with the first option. That was one of the things that stood out to me in the docs but I wasn't feeling as strongly about it as I did with the ones I mentioned.

Kimo17:11:01

I'm a fan of the third way lately.

p-himik17:11:32

IMO the top-level :input is just a let with a very narrow scope and a longer name. :) But without an additional nesting level and potential calls to merge.

Kimo17:11:49

Under the hood though, we use inputs to express the https://github.com/day8/re-frame/blob/aff2dc4cd925530f81e7cc7e85bbda7c8012e44a/src/re_frame/flow/alpha.cljc#L28 between flows. That's how one flow can react to another without risk of them running in the wrong order.

p-himik17:11:44

That makes sense, but that's an implementation detail that doesn't preclude the first way from being implemented. But my opinion is not too strong on this matter. The first option just feels simpler, there are fewer moving parts, at least at the API level.

Kimo15:11:29

> • A double-nested map makes our DSL feel awkward. > • Harder to drip-feed concepts in the https://day8.github.io/re-frame/Flows. > • Harder to talk about inputs. Technically they're the output-inputs and the live-inputs. I'm still finding these hard to dismiss, though. A key factor of re-frame's success, apart from its architectural model, is its code aesthetics. They make all our design discussions more reasonable. Another way comes to mind: • No more nested keys • Let :inputs be required and :live-inputs be optional. This lines up with the optionality of :live? itself. • Choose a good default for :live-inputs. Options: ◦ {}, since the default for :live? is just (constantly true) ◦ Same as :inputs, so that :inputs retains its simple premise (i.e. one node, one set of inputs) until you override it.

2023-11-06

Channels