search

JordanMartinez / learn-halogen

Learn purescript-halogen using a bottom-up apporach via this "clone-and-play" repository
188 stars 28 forks source link

Correct Halogen Flowchart's Input flow #37

Open JordanMartinez opened 5 years ago

JordanMartinez commented 5 years ago

On FP Slack: @garyb: I’m not sure that flowchart is quite right when it comes to input values. There’s nothing in Halogen that checks whether the input value differs at all, the user has to do that in the receiver - the receiver will be triggered for every child every time the parent renders. Also changing the input value does not reconstruct the component - that’s kinda the whole point :smile:I’ve written a bunch about the lifecycle in the new Halogen docs, I’ll push it somewhere so you can have a look and see if it matches your understanding, if that’d be useful?

me: Oh! Ok. I'll need to update that then...

garyb commented 5 years ago

Slack must have eaten my reply 🙂 - the relevant section is here: https://gist.github.com/garyb/55d24a0a81505bf88f4e9b22f4a6b525

JordanMartinez commented 5 years ago

So, these docs reveal two or three problems with this repo. First, the input type's value isn't checked with the past one automatically by Halogen (the current issue). Second, this repo doesn't say anything about the initializer's special limitations (e.g. asynchronous computations need to be forked. Otherwise, it will result in a deadlock). Third (?), the docs seem to indicate that one only needs a finalizer when using non-Halogen components or JS-land things.

garyb commented 5 years ago

I'm not sure (3) is necessarily a problem - if you're telling people they have to kill forks / unsubscribe from event source in a finalizer, it's harmless, just unnecessary.

garyb commented 5 years ago

(2) is a little more subtle than you outlined too - the deadlock is one possible problem there, but only with reciprocal initialization dependencies. The more common problem is that component appearing not to respond to interactions during slow async initialization, and then them all coming through in a batch some time later.

JordanMartinez commented 5 years ago

I think the issue is that I'm not currently able to explain to someone else with a real example of when killing a fork or unsubscribing is unnecessary and when it is necessary. The same goes for the second problem. I'd guess that some of this is due to my lack of understanding for how Aff works in some situations and the other part is just not having spent time playing around with it to see what occurs when I do various things. My focus is also not currently on this repo, so that's partly why I haven't addressed this yet.