Marc Cyr
Marc Cyr
Sep 7, 2018 · 3 min read

Hi Owen Ayres, thanks for the feedback! I’m glad to know writing this is of interest to you. To answer your initial question, I haven’t moved our project (the UI project at my company) over to React 16 yet. I know, I’m slacking :( I have a task on my plate to work on switching us over, but not sure when that work will be completed.

I am aware of what you’re referring to with the lifecycle changes. I just started reading up on the changes to try to understand the ramifications and what things will need changing throughout our application.

I’m looking back at the code and I do see a potential problem: the decorator creates a new pubsub instance each time, without checking first whether an instance of the namespace already exists. This is one thing I can see that should be addressed.

As far as both components unsubscribing when one unsubscribes, that is news to me. I’m looking at the source code for lsbridge right now and see this for unsubscribe:

This is a shortcoming I didn’t anticipate, or run into… fortunately for me, not so much for fellow programmers such as yourself. In our usage of the decorator, I have 1 namespace to 1 component… which is not helpful for your use case.

I think one solution to the issue could be the following: Instead of using a decorator that automatically unsubscribes for you, use the createPubSub method to create the shared namespace higher up in the component tree, and then through context you could access it further down the tree in the two different components for subscription. You could handle the unsubscribe when that higher-level component unmounts, instead of on each unmount of the subscribed components.

Another theory I have is that you could create a “global” bucket for pubsub instances. This would be initialized when the app initializes, and it could put all subscribers on context via the namespaces. So, say you have a “foo” namespace, your context through the app could have { foo: { send, subscribe} Then, throughout the app you could access the context anywhere and do what you need with a specific namespace.

In theory, if a company is not mounted that actual subscribes to the namespace, you could fire off whatever you want message-wise and it just wouldn’t get consumed anywhere… essentially, no harm no foul. This would allow you to send from anywhere. Then, if you only handle unsubscribe at that “global” level, you would not run the risk of messages not getting to their intended receiver.

When I say “global”, I don’t mean using the global browser space. I mean putting things on context. If you’re using Redux or a similar state management framework, you could put all these namespaces into redux and store the functions in there. Then, you could access everything through mapStateToProps.

I apologize than my response has both run long and was delayed a few days past when I wanted to originally respond. Let’s keep the conversation going about this. I want to know what ends up working. My theories are just theories… so they could be completely outlandish. Let me know what you think will work, or if you’ve solved it already!

    Marc Cyr

    Written by

    Marc Cyr

    Husband and father. Head of UI for Prisma Cloud at Palo Alto Networks running a large engineering team.