martinrosenberg / mess-hall Goto Github PK

• No quicker way to know if you broke something!
• Tests also serve as documentation.

Suggested implementation

Jest has already been installed for client and server, along with Enzyme for the client.

• Consider replacing Jest on the server. It was chosen for the fact that it was designed for testing React, but Mocha/Chai has a better API. On the other hand, having two different testing frameworks could just be frustrating.
• Cypress.io might be more useful on the front end than Enzyme anyway. Or both...?!

Steps to reproduce

1. Start both client and server.
2. Open two instances of the client in the browser.
3. Send a message from one of them.

Expected behavior

Each instance shows all messages.

Actual behavior

The other instance shows only a single ":". The following error is present in the console:

Warning: Each child in a list should have a unique "key" prop.

Check the render method of `ChatLog`. See https://fb.me/react-warning-keys for more information.
    in li (created by ChatLog)
    in ChatLog (created by App)
    in App

Suggested reason

The message is bouncing around and being added from multiple places. This creates a duplicate id, which ChatLog is using as the list key.

Suggested fix

A "quick fix" would filter out duplicates. But obviously that shouldn't happen to begin with, so figure out how to avoid duplicates.

There's literally no styling in this app except removing the bullets from the list.

Suggested implementation

• Use Emotion. It's like Styled-Components, but smaller and with more features.
• Use SCSS. It's like CSS, but with more features and less headache.
• Just pick one of the billion existing React/CSS frameworks like Reactstrap, you dummy.

That was primarily for quick testing. It's amusing but impractical.

It would be nice to have multiple channels/chatrooms to talk in.

As is, messages from outside (before or after) the current session are unavailable. Storing the history and bringing it back on startup resolves this.

Suggested implementation

• Most relevant tutorials/documentation revolve around the MEAN stack, so MongoDB would be very quick/easy to add, and would work just fine for the sake of this app. Also, as object structure gets more complex, a JSON(-like) document schema gets easier compared to a relational DB.
• Right now, the data is pretty simple and small, so something simple like SQLite would be a great start. That would also ease the transition to a different SQL database coughpostgrescough if that's called for later.

A chat app isn't much good if it's just being intermittently served from some rando's personal laptop.

Suggested implementation

This is pretty lightweight and unlikely to be used much. May as well put it up on Heroku and stop worrying about it.

Express is big and slow, bloated with dependencies, which is shocking for as minimal a tool as it is.

Suggested implementation

• The Express team themselves left to make Koa, which is very similar but uses promises/async and reduces external dependencies.
• Hapi has a bit of extra boilerplate and is designed more for enterprise software, but it is an interesting API. If more features are expected to make this app much bigger, not a bad choice. (Plus, it's a Ren & Stimpy joke.)
• Right now, there's not really a need for a server. Consider just removing it and using vanilla Node.js if new features don't dictate the need for anything more complex.

Important for filtering, sorting, and y'know, just knowing when the messages were sent.

Suggested implementation

Use date-fns. It's lightweight, pure, and small. No contest. (Don't forget it uses Unicode tokens for date formatting.)