Hi @oelmekki,
Could you share more on your issues with how Mattermost implements React?
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.