info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Using React in devtools frontend code
86 views
Skip to first unread message
Patrick Brosset
Jan 9, 2015, 6:43:03 AM1/9/15
to dev-devel...@lists.mozilla.org
tl;dr I tried React, and liked it. If we were to decide to go an use it for
our front-end code, I'd be happy.
--
I've been spending a little bit of time over chistmas and this week
learning more about React and applying what I did learn to a concrete
project: re-writing the markup-view panel (only as an experiment).
This email is not about me championing for the idea of using React in the
devtools because I simply don't know enough about it yet (and I'm still
somewhat uncomfortable with introducing a ui lib in a project like this,
knowing that new ui libs come and go very quickly these days).
However, I'm pretty confident after having tried it out that it's a good
fit technically.
Here are some of the advantages I can see:
- It would force us to (re-)write our panels in a consistent manner, making
it easier for new contributors to join (especially if they already know
React, or are interested in trying it out).
- The ui update flow is pretty amazing, just update the model and refresh
everything. The dom diffing mechanism really does seem to be pretty
efficient. I've worked in the past with a similar framework so I know the
feeling of "set something in the model, have the UI automatically update",
but the diff makes the update pretty mind-blowing.
- It enforces a clearer separation between the model and the view layers.
Components are far easier to deal with if they are small, single purposed
and stateless (they only accept input props but don't need to manage a
state of their own), and so with React, you tend to want to write them this
way automatically and that forces better reusability of common widgets.
- After spending a few hours writing a DOM node component to display it as
part of the markup-view, I didn't have anything else to do to make it
usable standalone somewhere else. I can now just render it on its own too
(today, we have specific code to display dom nodes in the variable view and
console).
- That also causes components to be easily swappable too, because they
don't depend on anything else than what input props they take. So, in the
markup-view for instance, I've realized it's very simple to switch from an
HTML-like tree view to a HAML-like tree view.
That's not to say that any of this can't be done without React of course,
most of these are just good design principles and we can apply them without
using React (except of course for the way it updates the DOM), but React
makes this very obvious and easy to do.
If you want to take a look at the code I threw together quickly for the
markup-view, check this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1118692
If you decide to apply the patch, be aware that I only have re-implemented
about 20% of the features, so don't expect everything to work as before.
--
Patrick Brosset
our front-end code, I'd be happy.
--
I've been spending a little bit of time over chistmas and this week
learning more about React and applying what I did learn to a concrete
project: re-writing the markup-view panel (only as an experiment).
This email is not about me championing for the idea of using React in the
devtools because I simply don't know enough about it yet (and I'm still
somewhat uncomfortable with introducing a ui lib in a project like this,
knowing that new ui libs come and go very quickly these days).
However, I'm pretty confident after having tried it out that it's a good
fit technically.
Here are some of the advantages I can see:
- It would force us to (re-)write our panels in a consistent manner, making
it easier for new contributors to join (especially if they already know
React, or are interested in trying it out).
- The ui update flow is pretty amazing, just update the model and refresh
everything. The dom diffing mechanism really does seem to be pretty
efficient. I've worked in the past with a similar framework so I know the
feeling of "set something in the model, have the UI automatically update",
but the diff makes the update pretty mind-blowing.
- It enforces a clearer separation between the model and the view layers.
Components are far easier to deal with if they are small, single purposed
and stateless (they only accept input props but don't need to manage a
state of their own), and so with React, you tend to want to write them this
way automatically and that forces better reusability of common widgets.
- After spending a few hours writing a DOM node component to display it as
part of the markup-view, I didn't have anything else to do to make it
usable standalone somewhere else. I can now just render it on its own too
(today, we have specific code to display dom nodes in the variable view and
console).
- That also causes components to be easily swappable too, because they
don't depend on anything else than what input props they take. So, in the
markup-view for instance, I've realized it's very simple to switch from an
HTML-like tree view to a HAML-like tree view.
That's not to say that any of this can't be done without React of course,
most of these are just good design principles and we can apply them without
using React (except of course for the way it updates the DOM), but React
makes this very obvious and easy to do.
If you want to take a look at the code I threw together quickly for the
markup-view, check this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1118692
If you decide to apply the patch, be aware that I only have re-implemented
about 20% of the features, so don't expect everything to work as before.
--
Patrick Brosset
David Bruant
Jan 9, 2015, 8:14:01 AM1/9/15
to Patrick Brosset, dev-devel...@lists.mozilla.org
Le 09/01/2015 12:42, Patrick Brosset a écrit :
> tl;dr I tried React, and liked it. If we were to decide to go an use it for
> our front-end code, I'd be happy.
>
> --
>
> I've been spending a little bit of time over chistmas and this week
> learning more about React and applying what I did learn to a concrete
> project: re-writing the markup-view panel (only as an experiment).
>
> This email is not about me championing for the idea of using React in the
> devtools because I simply don't know enough about it yet (and I'm still
> somewhat uncomfortable with introducing a ui lib in a project like this,
> knowing that new ui libs come and go very quickly these days).
I'm not sure what you mean by "a project like this". In any case, if
> tl;dr I tried React, and liked it. If we were to decide to go an use it for
> our front-end code, I'd be happy.
>
> --
>
> I've been spending a little bit of time over chistmas and this week
> learning more about React and applying what I did learn to a concrete
> project: re-writing the markup-view panel (only as an experiment).
>
> This email is not about me championing for the idea of using React in the
> devtools because I simply don't know enough about it yet (and I'm still
> somewhat uncomfortable with introducing a ui lib in a project like this,
> knowing that new ui libs come and go very quickly these days).
that makes any difference, know that Firefox's Loop (or is it Firefox
Hello, now?) already uses React today (so it means that a bunch of the
Mozilla process to have a JS lib accepted in chrome-context has already
been done)
See https://bugzilla.mozilla.org/show_bug.cgi?id=1033841 (as en entry
point). Reach out to Nicolas Perriault if you have any question on using
React at Mozilla. I'm sure he'll know everything you need to know.
I'm not sure what the problem is with "ui libs come and go quickly".
First off, Facebook looks commited as they use it fairly intensively.
Then, you may decide to use some version and stick to it.
I agree with everything else you wrote in your email :-)
I've been using React on lots of projects (among which one Firefox
addon) and I appreciate the discipline it imposes on the relationship
between data and UI components. Even if React was to fall out of
fashion, I know it's been influential and changes the way I think about
writing UIs.
In case not everyone knows, there is this James Long guy who's written
an amazing interactive blog post about the ideas behind React
(re-implementing the core of React features in a 250 lines of JS)
http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome
Worth a read. Like really.
(hi James! :-))
David
mratc...@mozilla.com
Jan 9, 2015, 9:09:49 AM1/9/15
to mozilla-dev-d...@lists.mozilla.org
tl;dr I also tried React, and I also liked it. If we were to decide to go an use it for our front-end code, I'd be happy and I believe a lot more people would contribute.
--
I am dyslexic so if I have used the wrong word somewhere try to think of a word with the letters shuffled around a bit and you will probably find the word I meant... I have been over the text a gazillion times so if I have made mistakes then try to see it as a game ;)
I also spent some time over Christmas looking into this so I will also share my findings:
Most MVC libraries don't scale well at all, see:
http://www.infoq.com/resource/news/2014/05/facebook-mvc-flux/en/resources/flux-react-mvc.png
Using React with Flux we would get this instead:
http://www.infoq.com/resource/news/2014/05/facebook-mvc-flux/en/resources/flux-react.png
Playing with React I found that I really liked it:
- Because the store represents the complete state of an app it would be very simple to add a few steps of undo / redo functionality or when a bug is encountered go back a step, save the store and add the JSON to a bug along with what to click next to reproduce... in fact, we may be able to automate that.
- I flew across to Portland with one of the Loop guys (they use Flux + React). He said that he has been amazed how much easier it is to test their components and how easy it is to find and fix bugs. He showed me a single page containing *all* of their components... that kind of capability has huge implications for theming.
- React + Flux it scales *really* well... that is the main reason they wrote it.
- Creating lots of components really encourages reuse and makes it easy to fix bugs e.g. we have a problem with the DOMNode component, I will go directly to that component to fix it.
- React's virtual DOM gives huge speed advantages over using web components.
- We have a lot of issues with slowdown on busy pages and the virtual DOM would help remedy this.
- React's is a smaller, simpler library than Angular and Ember.
- React is already used in our codebase.
- Facebook evaluated some ridiculous number of libraries to see what works best with a complex app and decided none of them were up to the job... they actually created React for that purpose.
- Your store represents your whole application so you don't need to worry about the small changes in your UI. Just update your store and the UI will reflect the change. This is probably one of the biggest advantages.
- It is way easier for new contributors to understand and contribute to the code. This obviously also means that the code is way easier to maintain.
- Because of it's component based approach it would allow us to e.g. have all HTML nodes as links to that node in the markup panel etc. etc. Firebug does way better than we do and it really unifies the tools.
- Using synthetic events (only one event on the document node) makes it way easier to avoid leaking events, in fact, it would make it almost impossible to leak them.
- Data only flows in one direction so we would never get into feedback loops.
- It is handy to prototype tools using a fiddle:
http://jsfiddle.net/reactjs/69z2wepo/
http://jsfiddle.net/fkadev/a2ms7rcc/
There is a small learning curve to getting started but it really isn't that big. egghead.io have some pretty cool videos but said they wouldn't give us a discount on a pro subscription (I just had to ask).
One note of caution though. It is easy to get lost in a sea of components so it becomes very important to name them well. Facebook have their devs give each component a long, descriptive name. If we do choose to switch to React then we should make sure we have a decent style guide... we know Facebook folks and I am pretty sure they have something reasonably comprehensive.
As far as using JSX or not the argument is that it is a lot easier to find out where a component's HTML is broken when it looks like HTML. I spoke to one of the React guys about this and he said that the best JSX to React converter is 6to5 with only the whitelist:react config set. We could use a custom require, maybe requireJSX() to load and convert the JSX into React DOM. Alternatively we can just not use JSX... I don't really mind either way but it may be easier for new contributors.
Apparently, there is also a library called DeLorien that makes it easier to manage Flux stores etc... the React guys say that it can be used in browser so it would be ideal for us.
--
I am dyslexic so if I have used the wrong word somewhere try to think of a word with the letters shuffled around a bit and you will probably find the word I meant... I have been over the text a gazillion times so if I have made mistakes then try to see it as a game ;)
I also spent some time over Christmas looking into this so I will also share my findings:
Most MVC libraries don't scale well at all, see:
http://www.infoq.com/resource/news/2014/05/facebook-mvc-flux/en/resources/flux-react-mvc.png
Using React with Flux we would get this instead:
http://www.infoq.com/resource/news/2014/05/facebook-mvc-flux/en/resources/flux-react.png
Playing with React I found that I really liked it:
- Because the store represents the complete state of an app it would be very simple to add a few steps of undo / redo functionality or when a bug is encountered go back a step, save the store and add the JSON to a bug along with what to click next to reproduce... in fact, we may be able to automate that.
- I flew across to Portland with one of the Loop guys (they use Flux + React). He said that he has been amazed how much easier it is to test their components and how easy it is to find and fix bugs. He showed me a single page containing *all* of their components... that kind of capability has huge implications for theming.
- React + Flux it scales *really* well... that is the main reason they wrote it.
- Creating lots of components really encourages reuse and makes it easy to fix bugs e.g. we have a problem with the DOMNode component, I will go directly to that component to fix it.
- React's virtual DOM gives huge speed advantages over using web components.
- We have a lot of issues with slowdown on busy pages and the virtual DOM would help remedy this.
- React's is a smaller, simpler library than Angular and Ember.
- React is already used in our codebase.
- Facebook evaluated some ridiculous number of libraries to see what works best with a complex app and decided none of them were up to the job... they actually created React for that purpose.
- Your store represents your whole application so you don't need to worry about the small changes in your UI. Just update your store and the UI will reflect the change. This is probably one of the biggest advantages.
- It is way easier for new contributors to understand and contribute to the code. This obviously also means that the code is way easier to maintain.
- Because of it's component based approach it would allow us to e.g. have all HTML nodes as links to that node in the markup panel etc. etc. Firebug does way better than we do and it really unifies the tools.
- Using synthetic events (only one event on the document node) makes it way easier to avoid leaking events, in fact, it would make it almost impossible to leak them.
- Data only flows in one direction so we would never get into feedback loops.
- It is handy to prototype tools using a fiddle:
http://jsfiddle.net/reactjs/69z2wepo/
http://jsfiddle.net/fkadev/a2ms7rcc/
There is a small learning curve to getting started but it really isn't that big. egghead.io have some pretty cool videos but said they wouldn't give us a discount on a pro subscription (I just had to ask).
One note of caution though. It is easy to get lost in a sea of components so it becomes very important to name them well. Facebook have their devs give each component a long, descriptive name. If we do choose to switch to React then we should make sure we have a decent style guide... we know Facebook folks and I am pretty sure they have something reasonably comprehensive.
As far as using JSX or not the argument is that it is a lot easier to find out where a component's HTML is broken when it looks like HTML. I spoke to one of the React guys about this and he said that the best JSX to React converter is 6to5 with only the whitelist:react config set. We could use a custom require, maybe requireJSX() to load and convert the JSX into React DOM. Alternatively we can just not use JSX... I don't really mind either way but it may be easier for new contributors.
Apparently, there is also a library called DeLorien that makes it easier to manage Flux stores etc... the React guys say that it can be used in browser so it would be ideal for us.
Patrick Brosset
Feb 10, 2015, 4:18:19 AM2/10/15
to David Bruant, dev-developer-tools
For info, Standard8 just published a blog post about Hello's use of React
and Flux:
https://blog.mozilla.org/standard8/2015/02/09/firefox-hello-desktop-behind-the-scenes-flux-and-react/
On Fri, Jan 9, 2015 at 2:13 PM, David Bruant <brua...@gmail.com> wrote:
> Le 09/01/2015 12:42, Patrick Brosset a écrit :
>
>> tl;dr I tried React, and liked it. If we were to decide to go an use it
>> for
--
Patrick Brosset
and Flux:
https://blog.mozilla.org/standard8/2015/02/09/firefox-hello-desktop-behind-the-scenes-flux-and-react/
On Fri, Jan 9, 2015 at 2:13 PM, David Bruant <brua...@gmail.com> wrote:
> Le 09/01/2015 12:42, Patrick Brosset a écrit :
>
>> for
Patrick Brosset
James Long
Apr 7, 2015, 4:01:17 PM4/7/15
to Patrick Brosset, David Bruant, dev-developer-tools
I meant to respond to this email a while ago, and post a few links that I
thought were great presentations from React Conf in January. Patrick,
excellent job digging into React and understanding the benefits it could
give us. Of course I agree.
I was going to write up some notes on how to learn React if some of you are
going to play with it, but I haven't had time and there's a lot on the web
already (supposedly my article that David posted is also a good
introduction :)).
Here are a few must-watch videos to see the flexibility and performance
that React could give us:
Hype! - A huge showcase of complex things React lets you do easily (at
least watch this one): https://www.youtube.com/watch?v=z5e7kWSHWTg
Beyond the DOM: How Netflix plans to enhance your television experience -
https://www.youtube.com/watch?v=eNC0mRYGWgc
Scalable Data Visualization - Really cool high-perf visualizations
https://www.youtube.com/watch?v=2ii1lEkIv1s
A lot more cool videos here: http://conf.reactjs.com/schedule.html
I'd really love to give React a chance; I think I'm going to just start
prototyping a few things to show you all what it would look like. It would
be huge for contributors too.
- James
On Tue, Feb 10, 2015 at 4:18 AM, Patrick Brosset <pbro...@mozilla.com>
wrote:
> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>
thought were great presentations from React Conf in January. Patrick,
excellent job digging into React and understanding the benefits it could
give us. Of course I agree.
I was going to write up some notes on how to learn React if some of you are
going to play with it, but I haven't had time and there's a lot on the web
already (supposedly my article that David posted is also a good
introduction :)).
Here are a few must-watch videos to see the flexibility and performance
that React could give us:
Hype! - A huge showcase of complex things React lets you do easily (at
least watch this one): https://www.youtube.com/watch?v=z5e7kWSHWTg
Beyond the DOM: How Netflix plans to enhance your television experience -
https://www.youtube.com/watch?v=eNC0mRYGWgc
Scalable Data Visualization - Really cool high-perf visualizations
https://www.youtube.com/watch?v=2ii1lEkIv1s
A lot more cool videos here: http://conf.reactjs.com/schedule.html
I'd really love to give React a chance; I think I'm going to just start
prototyping a few things to show you all what it would look like. It would
be huge for contributors too.
- James
On Tue, Feb 10, 2015 at 4:18 AM, Patrick Brosset <pbro...@mozilla.com>
wrote:
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>
0 new messages