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.
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.
FormidableLabs (https://github.com/FormidableLabs) is doing some very good work in the React ecosystem. Here are projects that I'm particularly excited about:
I'm currently building a React app while trying to explain how/what I do in weekly(-ish) videos. You can find the source code (along with links to videos) on github: https://github.com/yamalight/building-products-with-js
"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."
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.
It is a platform to build pipelines to showcase machine learning models on the web. You select input components, output components, and use the cvfy-lib python client to connect all these.
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.
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.
Contains documentation and unit tests, plus a few neat react tricks (like a custom React-router Route component and an accumulator saga), documented there:
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.
All I know is that it written in react and by what seems to be three, very passionate, brothers.
"MASAS.fm is going to be a platform on which all of an Artist's needs, from creating music, to getting it discovered, to selling it and playing at live events, can be met, for free. Thus eliminating the need for all the vicious middlemen that have placed themselves between Artists and their fans. Together, we can build that platform, one that will truly help all Artists, without ripping them off of their music rights!"
Also: I would highly recommend getting familiar with both npm and Babel/ES6/ES2015 -- even if you're not a node developer.
I found that understanding the tech was one thing, but when I actually started building my own projects I sought out community help with specific questions I had.
Ill plug our new project, Desklamp. Its a replacement for the Redux + React Router standard. These two just weren't built to work with each other and so take a lot of extra code. Desklamp solves this problem by delivering a single library that handles both state and routing.
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.
Source is here: https://spideroak.com/solutions/semaphor/source