Source is here: https://spideroak.com/solutions/semaphor/source
Swing by the #hearthsim IRC channel some time and ping me (jleclanche) if you are interested.
I hope the React is better!
Open source FTW
We'd love to have OSS help. We try to be as beginner friendly as possible.
Getting started is as easy as `npm install; npm start`. Here are our contributing docs - https://github.com/devtools-html/debugger.html/blob/master/C...
We have lots of great "up for grabs" issues for first time contributors - https://github.com/devtools-html/debugger.html/issues?q=is%3.... If you're interested, comment on one of the issues and it's yours.
This week we've had lots of first time contributors and there's a lot of low hanging fruit.
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
"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."
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.
Work in progress: https://github.com/Cloud-CV/cvfy-frontend
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.
I should've posted it before!
The code is also open source: http://github.com/nylas/n1
(I work at Nylas)
Contains documentation and unit tests, plus a few neat react tricks (like a custom React-router Route component and an accumulator saga), documented there:
They are also accepting of new contributors.
Basic feature set: Login, Sort/Filter/Search, Play Audio in Browser, Pagination, ...
No over engineered libraries: normalizr, redux-thunk, react-touter, enzyme ...
Tutorial to build your own: http://www.robinwieruch.de/the-soundcloud-client-in-react-re...
Just leaving this here for reference and as a resource.
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.
It even has user interface guidelines for the components.
A Guild Wars 2 Armory. Fairly impressive. You can view it live too https://gw2armory.com/
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.
check it out here https://github.com/desklamp-js/desklamp and feel free to make pull requests and submit issues.
good luck in your tech journey
It has just two reducers, uses redux-promise-middleware to make one ajax call, and uses Semantic-UI for the UI.
Provided by Airbnb.
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.