Using a reactive library in devtools

[Jaroslav Šnajdr]

Hello everyone,

increasingly often, it would help me a lot if I could use a reactive stream
library in devtools code. To subscribe to a stream of events and do a few
simple operations like throttling or debouncing.

Is there anyone else who is longing for such a library to be available in
devtools/client/shared/vendor?

What are your opinions about which of the many options should we use? RxJS,
most.js, Bacon?

Which of them is most suitable for use in the devtools codebase given that
there is no NPM build step?

Has this been ever discussed in the past?

Jarda

[Jordan Santell]

FWIW, the addon-sdk has a form of signal/channels inspired by Elm available
at `sdk/event/utils`[0] (see the Input and Reactor exports).

[0]
https://github.com/mozilla/gecko-dev/blob/master/addon-sdk/source/lib/sdk/event/utils.js

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[J. Ryan Stinnett]

On Sat, Oct 8, 2016 at 11:25 AM, Jaroslav Šnajdr <jsn...@gmail.com> wrote:

> increasingly often, it would help me a lot if I could use a reactive stream
> library in devtools code. To subscribe to a stream of events and do a few
> simple operations like throttling or debouncing.
>
> Is there anyone else who is longing for such a library to be available in
> devtools/client/shared/vendor?
>

I used RxJS v4 in a personal project, so I have a little bit of experience
with libraries like these (but just a little!). So far, I haven't really
felt the need to try one in DevTools myself. Lately I've been liking how
we're all roughly aiming towards a similar design with React, Redux, etc.,
so I would be a little hesitant to throw in reactive streams if it's only
used sporadically...

Can you give more details about where you'd want to use this? Is there a
specific tool you have in mind?

>
> What are your opinions about which of the many options should we use? RxJS,
> most.js, Bacon?
>

I would suggest most.js or RxJS v5 because of their perf improvements vs.
the others. However, I have not actually used these, so it would be best to
investigate the APIs of each before choosing. API design is a pretty
critical piece of a library like this.

>
> Which of them is most suitable for use in the devtools codebase given that
> there is no NPM build step?
>

They all appear to have single file UMD distributions that would be easy to
land. (We can always investigate NPM support for managing libraries
throughout our codebase if it's believed to be a priority. Some panels have
mostly worked around this by using Webpack, I guess.)

>
> Has this been ever discussed in the past?
>

I don't think it's been discussed before. There may have been brief
mentions of UI frameworks based on reactive libraries in passing
conversation, but I don't believe enough of us were familiar to discuss
them in detail (at the time, at least).

- Ryan

[Jaroslav Šnajdr]

On Mon, Oct 10, 2016 at 5:14 PM, J. Ryan Stinnett <jry...@gmail.com> wrote:

> I used RxJS v4 in a personal project, so I have a little bit of experience
> with libraries like these (but just a little!). So far, I haven't really
> felt the need to try one in DevTools myself. Lately I've been liking how
> we're all roughly aiming towards a similar design with React, Redux, etc.,
> so I would be a little hesitant to throw in reactive streams if it's only
> used sporadically...
>
> Can you give more details about where you'd want to use this? Is there a
> specific tool you have in mind?
>

I'm currently refactoring the Netmonitor tool to React/Redux and there are
at least two places where I could use a reactive stream:

At [1], we listen to two resize event streams (one from window, one from a
splitter element), merge them into one, debounce by RESIZE_REFRESH_RATE
(50ms) and then do some action (e.g., dispatch a "resize" action to the
Redux store).

At [2], we listen for search box keyboard events, debounce, and update the
filtering criteria.

The debounce logic is reimplemented again and again, sometimes with Chrome
timer APIs. And it's hard to things like creating the event stream in one
component and then passing it as a parameter to another component.

Of course, these two use cases are very simple and don't themselves justify
adding a new big library. But I believe that across the devtools codebase,
they are frequent enough to make a RX library worth it. It could be a
universal tool similar to promises or Task.js.

Also, I think a RX library is perfectly orthogonal to Redux - there is no
dilemma like "do X with Redux or with RX?", but rather these tools are
complementary to each other. Just another tool for async programming, like
promises or Task.js. Or am I wrong?

> I would suggest most.js or RxJS v5 because of their perf improvements vs.
> the others. However, I have not actually used these, so it would be best to
> investigate the APIs of each before choosing. API design is a pretty
> critical piece of a library like this.
>

As far as I'm concerned, I can live happily with any of the APIs - they are
not different enough from each other to make me care much.

Jordan mentioned a sdk/event/utils module - however, this one can't be used
in a non-privileged chrome code, and doesn't have the throttle/debounce
APIs I'd like to use.

Jarda

[1]
http://searchfox.org/mozilla-central/source/devtools/client/netmonitor/netmonitor-view.js#2446-2450
[2]
http://searchfox.org/mozilla-central/source/devtools/client/netmonitor/netmonitor-view.js#1035-1047

[J. Ryan Stinnett]

My initial reaction is let's just try it and see how it goes. It's hard to
know otherwise. Maybe it would be interesting to ask for review from
someone on the team not directly working on Net Monitor stuff for this, to
get an "outsider" (relatively speaking...) perspective on how it fits in
the codebase. (I could review it, but maybe it would be even better with
someone who hasn't used a reactive stream lib before...?)

If it ends up that it's only used in one place, we can come back and
refactor that one thing to be much simpler.

> Also, I think a RX library is perfectly orthogonal to Redux - there is no
> dilemma like "do X with Redux or with RX?", but rather these tools are
> complementary to each other. Just another tool for async programming, like
> promises or Task.js. Or am I wrong?
>

Right, I agree. I just meant that, similar to promises, it's a new
conceptual model to be aware of that affects the structure of code. It can
take a while to grasp at first, so that adds a barrier to jumping across
the codebase for those who haven't seen it before.

Anyway, it's not like we're trying to add new concepts like this all the
time, so I am not too worried yet.

> > I would suggest most.js or RxJS v5 because of their perf improvements vs.
> > the others. However, I have not actually used these, so it would be best
> to
> > investigate the APIs of each before choosing. API design is a pretty
> > critical piece of a library like this.
> >
>
> As far as I'm concerned, I can live happily with any of the APIs - they are
> not different enough from each other to make me care much.

At the moment, most.js seems like the strongest contender to me, mostly
based on its focus on performance. I re-ran their perf tests locally and it
still has a significant lead over the others. Since you said the API seems
workable to you, I'd say go for that one.

- Ryan

[Jaroslav Šnajdr]

On Tue, Oct 11, 2016 at 3:55 PM, J. Ryan Stinnett <jry...@gmail.com> wrote:

>
> My initial reaction is let's just try it and see how it goes. It's hard to
> know otherwise. Maybe it would be interesting to ask for review from
> someone on the team not directly working on Net Monitor stuff for this, to
> get an "outsider" (relatively speaking...) perspective on how it fits in
> the codebase. (I could review it, but maybe it would be even better with
> someone who hasn't used a reactive stream lib before...?)
>

OK, so my next steps will be:

1. Start using most.js in my netmonitor.html
2. Check if it makes the code really so good and beautiful as I expected
3. Ask someone to review if this style makes sense. I'm thinking about
jlongster, as he has experience both with Redux and with reactive
programming (js-csp, transducers...)
4. Also ask someone who has little experience with that, to get some
insight how readable is the code for people unfamiliar with FRP.

Jarda

[J. Ryan Stinnett]

Sounds like a solid plan to me, thanks Jarda!

- Ryan

[James Long]

I'd be happy to review it. I think this make sense. Thanks!