No offense, but I feel like this is not a good example to follow.
The first examples are better off with just using snapshots. Even if the author is trying to explain the concepts, it is really poor to show bad examples that could be covered by a simpler solution. If I read that and didn't know about snapshots, I'd think to myself, "why am I testing strings?" and then skip testing entirely.
Mocking Axios also seems like the wrong way to approach things. I'd extract the networking code from the presentation code. Possibly by using mobx-state-tree (which is an epic solution to a hard problem). This way, I wouldn't even need to mock Axios at all and I could then just take advantage of snapshots again by providing actual mock data to my components directly.
IMO its origins in the gaming community, and all the moderation features that grew out of it, make Discord a much better fit for open source communities than Slack. For example:
- Individuals can block and report other users
- There are tiered mod levels
- Per-community pseudonyms, but a single account makes it easier to track bad actors
Markdown support, including syntax highlighting, is actually better in Discord than Slack already, too.
If you haven't checked out an OSS community on Discord yet here are a few:
- A tiny one for my company, which we use much like one would use Slack within a company, including voice and video chats.
- A medium-size one for the open source community around the company. It includes project-specific channels (three-way mirrored between Gitter and IRC thanks to the wonderful Matterbridge: https://github.com/42wim/matterbridge/), general channels, voice channels etc.
- A large (20k users) one for our company's (gaming-centric) userbase.
Discord is a fantastic tool that adapts to all three situations very well, scales really well from 4 people to 100k people. Its DM/friendslist system scales a lot less well, but is still very usable with 100+ DM channels. I have even created a personal (private) Discord server where I'm keeping a journal of what I work on, inspired by a HN post the other day (https://news.ycombinator.com/item?id=15823599).
Discord is scalable messaging UX done right. I'm a huge believer in what they do. (Yeah, if only it were open source etc, I get it; different problem, different story)
I much prefer it over Gitter for open source chat (Gitter's only real advantage is how well it integrates with Github). And IRC is... well, not in a good state today. IRCCloud.com does wondeful work but they're small and it's just not enough.
I just wish Discord would get phonecall support, but that part is probably not going to happen. It's doable with a bot though. PhoneCord (https://www.reddit.com/r/discordapp/comments/6hlesz/anyone_e...) used to do it, they were shut down because of the obvious abuse implications but I'd really like to hook up Twilio with Discord in a bot for my company, internally, so we can do phone conferencing from it.
> And IRC is... well, not in a good state today. IRCCloud.com does wondeful work but they're small and it's just not enough
Would love to hear more about the reasoning behind this. IRC might not be as flashy as Slack, but for my daily work and communication, it works fine (I use IRCCloud) even though I would love for IRCCloud to offer a bouncer so I can use my own client.
AFAIK, the only way Gitter "integrates" with Github is sending repository updates to the channel, something which Github has a webhook for doing with IRC as well.
Re Gitter: It integrates with the repository (eg. pasting commit hashes, bug numbers etc creates a link). It also has github signin. These things are really nice.
Re IRC: I absolutely hate Slack, but IRC holds no candle to Discord. Scrollback, search, highlight management, moderation tools, usable permission system, voice support, video support, low barrier of entry, online permanence, excellent file upload/image support, account-based identities, role customization and role-based permissions, support for profiles, drop-in group chat, markdown support with syntax highlight, multiline messages... am I done yet?
In other words, Slack merely tolerates public Slack chats, it doesn't want to encourage them.
As we speak, I have five slack communities open in my messenger. All but one of them are open to the public.
I'd wager there are more public Slack communities than there are private (i.e. "team chat") ones. But much like Twitter, Slack has a fundamentally different vision for their platform than their users apparently have.
To me this was first made clear when Reactiflux (a massive community around React, Flux and related web technologies and topics) had to switch from Slack to Discord because they had hit a hard limit of members and Slack said they wouldn't increase it because their software and infra wasn't build to handle these scenarios.
Nevertheless open source projects and community builders keep flocking to Slack and Slack doesn't seem to have any intention to clear up this misalignment. They're benefiting from the free advertisement small public communities create but don't want to spend any extra energy providing their services to them as they grow.
Anyone know how they gained traction in the gaming community? Their wikipedia entry [0] says they had a game development studio which developed games that were not successful, then they start developing Discord and successfully launch on reddit. How did they promote on reddit given reddit's aversion to self promotion? Maybe ads? Would love to learn more about their early days.
[anecdotal] In our little fighting game community, our tech-savvy guys got tired of trying to add features to the IRC channel, so when they heard of Discord they just convinced everyone to switch to that. It's easier for Facebook-followers to follow a link to Discord than ask them to download an IRC client -> open #server -> open #channel
And also the centralization + how easy it is to join a new Discord channel. It used to be very annoying to have to run vent/mumble and skype while playing a single game because of different groups/teams preferences. Not to mention, people had problems configuring vent/mumble all of the time. I've had times where my own configuration would randomly stop working. In, I guess about 2 years of using it, I've never had an issue with Discords voice.
A framework like Phoenix would be awesome. Even something more lightweight (Express-like) would be pretty handy. Clojurescript front-end, Clojure backend...
CSS-in-JS libs like https://emotion.sh make "micro-componentization" even easier - pretty much every raw DOM element can be replaced by a domain-relevant/ui-relevant component type. Then if you need to add something beyond styles like state or complex render logic, the consumers don't even know about it because the reference is the same.
Fastify is a similar project that aims to be faster than Express and adds a number of API improvements like baked-in schema validation for routes, logging, and async-by-default APIs.
Haven't used it in production but replaced Express with it in some side projects.
Since server.js is built on top of express it might even be possible to build a variant of it on Fastify instead and get those benefits as well.
This would be a good checklist for anyone considering building a UI framework. This kind of thing is the reason Bootstrap & friends are so large - they do a lot for you.
Still, it isn't entirely obvious under what conditions the methods of a React Component class are going to be called. For all you know they might always be called against the instance.
