Halogen.Wormhole

#1

Hi all,

I needed this for a project where I had a very dense hierarchy of components which was very expensive to emit data from the top down to the bottom which was only used in a very rare case and did not affect visual rendering.

So for this very specific case, I made a tiny module that lets me subscribe to a single value.

Sharing in case it’s useful or someone has done something similar and/or better.

6 Likes
#2

Very cool

It sounds like something you could also achieve with Thomas’s purescript-halogen-store. Though there’ll be more boilerplate to wire it up as it’s meant to scale beyond the single sender/receiver of your wormhole. (though, that said, it appears your project is on Halogen 5, and I’m 80% sure the Halogen Store library isn’t compatible until 6+ anyway).

But if you’re working with a project using Halogen 6.x, then you could use the following two methods to achieve the same thing. i.e.

  1. Use updateStore in the component eval that’s sending the data.

  2. In the initialize action of the component receiving the data, both
    a. Use emitSelected to create an Emitter, then
    b. Halogen.subscribe to it

And this will let you skip sending the data as input down through each node of the component hierarchy between the two points.

2 Likes
#3

Is this similar to halogen-subscription?

#4

Definitely similar. My impl. re-uses the subscribe infra of halogen, which I’m already using for other tasks, and unsubscribe automatically works when the component is destroyed, which is nice. I’m not sure about the history but I thought that package was perhaps folded into Halogen at some point.

It is indeed.

Can you explain that?

Interesting, I’ll check that out! Thanks for sharing!

#5

I mean specifically purescript-halogen-subscriptions/Subscription.purs at 95dfd40ec490ac847b9fe458e5821acba3e30ff5 · purescript-halogen/purescript-halogen-subscriptions · GitHub

If you are on 5 still, I’m not sure how much is reusable.

#6

That module seems to reimplement what’s already in Halogen 5 built into the component lifecycle.

https://pursuit.purescript.org/packages/purescript-halogen/5.0.0/docs/Halogen.Query.HalogenM#v:subscribe
https://pursuit.purescript.org/packages/purescript-halogen/5.0.0/docs/Halogen.Query.EventSource#t:EventSource
https://pursuit.purescript.org/packages/purescript-halogen/5.0.0/docs/Halogen.Query.EventSource#t:Emitter

So there doesn’t seem to be any reason to use that package.

Perhaps in Halogen 6 they removed subscriptions or factored it out. If so, that might be the final nail in the coffin for me to move on from Halogen and just fork it. Can’t deal with the API churn.

1 Like
#7

In Halogen 6 the implementation for subscriptions moved to the halogen-subscriptions library and no longer uses coroutines. The changes I had to make to my applications were pretty small. You can see the changelog for the Halogen 6 release here, which includes advice on how to update your code:

Halogen 7 has no changes besides support for PureScript 0.15, so you’ll find the API is remaining stable through that release.

2 Likes
#8

Thanks Thomas! I’m very slow and very conservative with my use of PureScript and its packages, but I’ll keep that in mind if I decide to upgrade. The migration guide is very appreciated in any case.

1 Like
#9

If you are interested in upgrading, you can see the changes in Halogen 7 here or in the corresponding migration guide:

You’ll be unaffected from Halogen 6 to Halogen 7 unless you use the autocomplete property or you are still using the deprecated id_ function.

1 Like