Correct Way to Pass a Callback Function to a Child

[born2defy]

I have been playing with this library, I am curious what the correct way is to pass a callback function to a child element and what the type should be? In the child who is expecting a call back function in its props, what should the type of the callback function be (especially if we don't know the type of the parent yet that will be providing the callback function)? It seems like all the event handlers are parameterized to a specific element's props and state.

Also - if the child itself is responding to an event (like a click event), is there any way for the child to respond to the event locally (make a state change) and then call the parent's callback? It seems like the types of the two event handling functions (child and parent) conflict.

Finally, is there any way to add a callback to a child's componentWillMount or other life cycles hooks? The ReactSpec is typed so that all the types in the spec must match, so if we ran a parent's callback on a child's mount function we would get type issues, no?

Just curious how others are handling this or if there is an idiomatic way of solving this without having to put all the state together in one place.

[paf31]

This library is pretty low-level doesn't make any assumptions about how inter-component communication works. The effects seem to get in the way, but reflect the fact that state updates etc. should only really be happening inside render and the lifecycle methods.

Some other mechanism for updates (such as AVar or Observable/Subject) needs to be used if you want to send data between components. You would need to capture the state callback inside some initializer, and publish it to other components.

Edit: You might like to look at https://github.com/kRITZCREEK/FROST-Frontend.

[born2defy]

Ok, I see. I was wondering why I kept hitting a brick wall trying to replicate some basic react structures where the parent registers callbacks with the child to get updates (just could never get anything meaningful to type check). I think Kritzcreek used raw react in his Frost project thru the FFI, so not sure that he worked within the available bindings. If I did implement an ad-hoc event system for intra-component communication, where would it be best to fire the events from? The react render method? I guess I could create a new Effect and use that as the polymorphic effect type. Has anyone done anything similar that I might be able to look at?

[AlexeyRaga]

I am frying to find a solution to the same problem: composing components into a parent-child structure with the ability for the child to "emit" something to the parent using purescript-react and purescript-thermite. Surprisedly it looks much more complicated than I expected.

Can anyone advice for or against using purescript-signal as such a "callback" mechanism?
For example, a channel could be passed as a part if component's props... Any ideas here?

Also, does Halogen has a nicer solution? If yes then are there any examples of such composition?

[born2defy]

Check this out: https://gist.github.com/kRITZCREEK/cdf9f403b55b345cdc51 This helped me figure out how to integrate react with signals.

[AlexeyRaga]

Yeah, I have something like that currently working. It seems a little bit inconvenient for an arbitrary parent-child composition, mostly because creating a channel returns an Eff monad.

That's why I am asking for the advice: I must be missing some composition abstraction here.
Maybe creating components should result in Eff and then we use bind to compose them together? Haven't played with it enough yet...

[born2defy]

It is a bit inconvenient as there is no way to avoid the Eff monad. You can create an abstraction for each component (something like the signal-loop package), but you still end up having to tie it back into your main function unless you want to pollute everything with Eff, as you need to generate the channels at some point. Initially I have been playing with this approach as a way to create components which encapsulate an inner state/action model but can also broadcast updates to other components as well. However, the more I work with it the more I am leaning towards an abstraction like Thermite where there is no encapsulated state and each component is essentially internally stateless, operating only on a subset of a larger app state and action set (through lenses and prisms). At first I was weary of including all state and actions (however local they seem) in a central location at top-level, but I am beginning to see the advantages in that approach.

[AlexeyRaga]

Hmm, thanks for the info.
I see how Thermite works with the global state, but I was a bit sceptical about it since I thought that I don't actually need any state. I just wanted some sort of notification which would result in changing props and re-rendering.
But I'll think about it again.

[born2defy]

The way that I have been thinking about Thermite is to imagine that the small piece of state your component subscribes to using its lens is essentially the same as the props you would feed it. So, instead of feeding props from the outside, the props are kept in a global state and fed in via a lens. Then when the props/state change, the child re-renders. The global state/lens abstraction serves as both the event system and the re-rendering system.

[paf31]

Fixed by #52.