Suggestions for a healthy codebase

[lsjroberts]

It's great seeing so many people contribute to the project, and it's refreshing for me to work on something without all the burden of external frameworks and dependencies. But I think there are a few things we could do to make it easier to maintain and to help new folks get involved (from a code point of view).

It may feel a little early to start looking at this stuff, but it's easier to adjust now before it becomes unwieldy and requires major refactoring.

Please discuss :) I'm not just doing them immediately as there are many other valid opinions.

Consistent code style with prettier

Prettier is an amazing tool to help keep your code clean and consistent. It can help when reading the code, and prevent any disagreements if you leave the way it looks up to a tool.

It can be setup to run in a couple of different ways:

• Configure your editor to run it when you save a file, most editors have plugins for this
• Add it as a prepush git hook, I'd suggest using a couple of npm scripts to do this

Separating the logic and view layers

Essentially you have all your code that does things like get the data from the archives, mutate it however etc in one place, and all your code that renders it into the dom in another place. This helps in both the reading and understanding of the code, but also prevents a lot bugs, duplication of code, ease of testing, adding new features and performance optimisation.

We definitely do not need any external libraries like this, and to keep it simple I'd suggest not unless we really feel we need to. (You may have heard of Redux (data) and React (view)).

Adding tests

Once the data logic is separated it is pretty easy to test it. We wouldn't need too much testing but it'd help us be confident in new PRs and prevent bugs.

There's a bunch of libraries for this but I've found the most success with Jest.

Automating tests with CI

I suggest we could use Travis CI for this. It is free for open source projects and very easy to setup and use.

[maxdeviant]

@lsjroberts I 100% agree about using Prettier.

I was thinking about the prospect of using React for this as well, especially after seeing #42 and #46. I think the main concern is keeping it accessible for newcomers. I think if we can get React plugged in without needing a build system, then it would be a viable option.

The other alternative would be to have multiple example projects using various technologies so people can choose based on their preference.

[lsjroberts]

I think if we can get React plugged in without needing a build system, then it would be a viable option.

Yeah the build stuff is what I want to avoid.

We could use raw react instead of jsx:

React.createComponent('div', { className: 'hello' }, 'Hello')`

The downside is that is still ~160kb of extra stuff. (About ~50kb gzipped if Beaker does that?)

It does also have some pretty handy error handling stuff we can use in React 16.

But still, it may be sensible to see how far we can get with just standard dom apis. A couple of helper functions should reduce the repetition and be easier to understand for new folks. I wouldn't want to exclude anyone who isn't familiar with React.

The other alternative would be to have multiple example projects using various technologies so people can choose based on their preference.

A good idea, but it would be very hard to maintain feature parity. (site note: I was thinking about doing an example in Elm but more as an example of Beaker API usage in Elm.)

[neauoire]

I'd prefer if we did not use libraries, although, we could make a secondary repo with a React client. I know @joperron was working on something along these lines the other night.

[lsjroberts]

@neauoire Agreed. We should be able to do it without them.

[maxdeviant]

@neauoire Wait until you see what I have up my sleeve for Rotonde :crystal_ball:

[neauoire]

I'm excited to see!

[joperron]

We can probably use Preact for this. The overhead in terms of tooling is pretty hefty but once built it's pretty lean and I think the pros outweigh the cons. Will look into it next weekend!

[cblgh]

yeah so just to be clear the rotonde-portal & rotonde-client repos will likely never have any libraries, but a rotonde-portal-preact could be a separate thing and very welcome indeed!

(personally i might build something using choo :3 - we'll see!)

[maxdeviant]

@cblgh I think that's the best approach to take.

Let a thousand flowers bloom :rose:

[webdesserts]

I think web components might be a good fit for the Rotonde view layer. Wouldn’t require any third party libraries.