I remember doing a lot of WP consulting in the 2006-12 timeframe. The PHP was (is?) god awful. Difficult to parse, difficult to follow, and followed no discernible best practices. Spaghetti all the way down.
ES6 React with react-router, server side rendering, and Webpack code splitting + tree shaking. It's based on the "huge-app" example from the react-router project.
Not sure just what you're looking for, but SpiderOak's Semaphor is a desktop/mobile end-to-end-encrypted Slack alternative where the presentation layer is React, and the client side app backend (networking, crypto, database) is Go. That keeps the React code focused and easy to follow.
"debugger.html is a hackable debugger for modern times, built from the ground up using React and Redux. It is designed to be approachable, yet powerful. And it is engineered to be predictable, understandable, and testable.
Mozilla created this debugger for use in the Firefox Developer Tools."
As much as I'm reluctant to blame people who try to get cool products out there, I must say that I actually uninstalled mattermost from my server (well, deactivated from gitlab) after reading its source code, both go and react. I would not recommend to use it to learn react.
Sorry I had to say that, I know how depressing it can sound. Note that we're in the context of recommending examples to someone wanting to learn about react, so there's an expectation about finding the best code around.
The general critic I would make about Mattermost's React source code is that it does not take advantage of react composable nature, and instead just drop all the code in huge render methods, which are fairly difficult to read, and probably to maintain.
The render method takes 170 lines, putting tons of "stuff" in. This file could easily have been split into 15 to 20 components to make it easier to reason about.
Almost 200 lines in the same function, containing rendering, looping, conditional execution, more rendering, that is, about everything. This should be split into more components and more functions. Most of files can be taken as such examples.
I think that's actually a problem for Mattermost, because when you run someone else code on your server, you take the responsibility for security breaches. I know how horrible this sounds, it's super cool to be able to run a slack-like app for free, self hosted. The thing is, reading the code, I'm not confident the tools used has been properly understood yet, which in turn makes me reluctant to execute it on my servers.
I wish you the best, though, you're on something with Mattermost!
EDIT: please also note this is not just Mattermost. I usually review part of code of apps I want to put on premise, and decide whether to keep them or not based of my level of confidence in it.
Mattermost started in the early days of React and you're right not all the patterns were in place from the start--and you've pointed out areas we know we want to re-write.
For example, how would you break the re-write into parts, and prioritize?
How might we organize tickets for people to help?
On Wednesdays at 10am California time we have open developer meetings via Hangouts if you're up for speaking in person (or any time really, we're always looking for feedback).
Just a thought,
What I would note is that we have significant test coverage on the Mattermost server and hundreds of manual tests run for each release, so the quality of the end product is generally high, even if the React code isn't pristine.
I would say the Mattermost project is closer to the beginning than it is to the end. Significant refactoring is on our roadmap, and we'd highly welcome help.
Sure! I'm already under contract half time, and I work on my own company for like two full time, so I can't be a big contributor, but I contribute here and there to open source projects, so I can look around from time to time.
> For example, how would you break the re-write into parts, and prioritize?
I would probably do it component per component, factoring out complexity one method at a time. I avoid "big rewrites", aka v2 or whatever, because I've seen too many startups doing that to disastrous consequences (typically: a whole dev team not releasing anything for like a year, and a "new" app that is at the end not better than the previous one). Not really a surprise: v1s are iterated on and always keep track of reality, by releasing often - which v2s never do, they just try to bring everything at once.
> How might we organize tickets for people to help?
I guess people at Gitlab have way better ideas than me, given how successful they've been at that :) I see you already have a "help wanted" section, that's probably the most important, so contributors can quickly spot low hanging fruits and help a bit.
https://github.com/callemall/material-ui is a great collection of components -- there's perhaps some insight into how to make (and document!) reusable components, since the project is built to be a component library for others' use
WordPress.com front end is written with React. It's one of the biggest React projects, and it is used in production. We are actively developing on GitHub and trying develop out in the open.
A website and user system starter. Server side is built with hapi.js. The front-end is built with React. Redux as the state container. Client side routing with React Router.
I highly recommend checking out React Toolbox [http://react-toolbox.com/#/]. It's a horrible name for what it is - but it's a Material Design implementation in React.
There are simple components, and then more complicated concepts like higher-order components and factories. It has very good documentation, and is under active development.
FormidableLabs (https://github.com/FormidableLabs) is doing some very good work in the React ecosystem. Here are projects that I'm particularly excited about:
74 comments
[ 2.7 ms ] story [ 204 ms ] threadhttps://github.com/andrewngu/sound-redux
https://developer.wordpress.com/calypso/
https://github.com/Automattic/wp-calypso
I hope the React is better!
https://react.rocks/
https://github.com/robinjoseph08/pokedextracker.com
https://github.com/react-bootstrap/react-bootstrap
They are also accepting of new contributors.
https://github.com/5tefan/universal-react-demo
Source is here: https://spideroak.com/solutions/semaphor/source
https://gitlab.com/presenter.club/presenter.club/tree/master...
https://www.presenter.club/
"debugger.html is a hackable debugger for modern times, built from the ground up using React and Redux. It is designed to be approachable, yet powerful. And it is engineered to be predictable, understandable, and testable.
Mozilla created this debugger for use in the Firefox Developer Tools."
[1] https://github.com/devtools-html/debugger.html
[1] https://www.mattermost.org
Could you share more on your issues with how Mattermost implements React?
Sorry I had to say that, I know how depressing it can sound. Note that we're in the context of recommending examples to someone wanting to learn about react, so there's an expectation about finding the best code around.
The general critic I would make about Mattermost's React source code is that it does not take advantage of react composable nature, and instead just drop all the code in huge render methods, which are fairly difficult to read, and probably to maintain.
Here is an example: https://github.com/mattermost/platform/blob/master/webapp/co...
The render method takes 170 lines, putting tons of "stuff" in. This file could easily have been split into 15 to 20 components to make it easier to reason about.
Same here: https://github.com/mattermost/platform/blob/bb69e98631b25419...
Almost 200 lines in the same function, containing rendering, looping, conditional execution, more rendering, that is, about everything. This should be split into more components and more functions. Most of files can be taken as such examples.
I think that's actually a problem for Mattermost, because when you run someone else code on your server, you take the responsibility for security breaches. I know how horrible this sounds, it's super cool to be able to run a slack-like app for free, self hosted. The thing is, reading the code, I'm not confident the tools used has been properly understood yet, which in turn makes me reluctant to execute it on my servers.
I wish you the best, though, you're on something with Mattermost!
EDIT: please also note this is not just Mattermost. I usually review part of code of apps I want to put on premise, and decide whether to keep them or not based of my level of confidence in it.
Highly appreciate the feedback--critique is valued, and we welcome hearing it publicly.
It benefits Mattermost to have more people with deep React experience looking over the project and suggesting changes.
One example is the discussion that influenced us to adopt React Router: https://github.com/mattermost/platform/issues/790
Mattermost started in the early days of React and you're right not all the patterns were in place from the start--and you've pointed out areas we know we want to re-write.
We're doing this by starting fresh with new React Native apps using Redux: https://github.com/mattermost/mattermost-mobile
The goal is to create a model for the future with React and Redux, and move that back into the server.
Would you be interested in dropping by our Developer channel some time (https://pre-release.mattermost.com/core/channels/developers) and maybe just hanging out with us and sharing more of your thoughts?
For example, how would you break the re-write into parts, and prioritize?
How might we organize tickets for people to help?
On Wednesdays at 10am California time we have open developer meetings via Hangouts if you're up for speaking in person (or any time really, we're always looking for feedback).
Just a thought,
What I would note is that we have significant test coverage on the Mattermost server and hundreds of manual tests run for each release, so the quality of the end product is generally high, even if the React code isn't pristine.
I would say the Mattermost project is closer to the beginning than it is to the end. Significant refactoring is on our roadmap, and we'd highly welcome help.
> For example, how would you break the re-write into parts, and prioritize?
I would probably do it component per component, factoring out complexity one method at a time. I avoid "big rewrites", aka v2 or whatever, because I've seen too many startups doing that to disastrous consequences (typically: a whole dev team not releasing anything for like a year, and a "new" app that is at the end not better than the previous one). Not really a surprise: v1s are iterated on and always keep track of reality, by releasing often - which v2s never do, they just try to bring everything at once.
> How might we organize tickets for people to help?
I guess people at Gitlab have way better ideas than me, given how successful they've been at that :) I see you already have a "help wanted" section, that's probably the most important, so contributors can quickly spot low hanging fruits and help a bit.
- http://breakerapp.com/r/breakerapp
- http://github.com/larvalabs/breaker
A Guild Wars 2 Armory. Fairly impressive. You can view it live too https://gw2armory.com/
It even has user interface guidelines for the components.
Just leaving this here for reference and as a resource.
https://github.com/Linode/manager
https://github.com/Automattic/wp-calypso
Videos: https://www.codemy.net/channels/react-foundation
Source Code: https://github.com/codemy/invoiced-ui
https://jedireza.github.io/aqua/
https://github.com/jedireza/aqua
There are simple components, and then more complicated concepts like higher-order components and factories. It has very good documentation, and is under active development.
1. Spectacle (https://github.com/FormidableLabs/spectacle), Presentation Library
2. Victory (https://github.com/FormidableLabs/victory), Graphing Library
3. Radium (https://github.com/FormidableLabs/radium), Component Styling
React Native, but same idea. There's also an excellent set of posts at http://makeitopen.com/ which run through how it was built and why.
It's responsible for a lot of my 'aha' moments about Flow type-checking and Redux.
https://github.com/HearthSim/Joust
Example: https://hsreplay.net/replay/rjUdp6iC5FcQmKGmLX35RA
https://github.com/HearthSim/HSReplay.net
https://github.com/HearthSim/python-hearthstone
https://github.com/HearthSim/Hearthstone-Deck-Tracker
https://github.com/HearthSim/HearthstoneJSON
https://github.com/HearthSim/extract-scripts
Swing by the #hearthsim IRC channel some time and ping me (jleclanche) if you are interested.