Introduced a React component based design approach

[calvinrbnspiess]

In regards to #7, this PR includes a component based design. The idea is to describe every design as a react component, so you can just change to another design (that was transformed into a component before) through referring to another component inside your renderer. These components are written in JSX, a mix of .html and javascript (and perhaps even CSS) and transpilled using babel. to The component will automatically get all necessary properties and the browser will render the appropriate page like a charm. Currently, only one design is implemented to demonstrate the behavior. When you click the really-link you will get randomly redirected to the other designs based on regular .html files. I also changed the directory structure to something more emphasizing, flexible and switched the github badge. You can access a demo page at: https://vailfire.github.io/afullstop/notaperiod/

☑ Current state of work:

• [x] Include the other designs from the gh-pages-branch 1fe4ba9
• [x] Create a webpack workflow that allows developing components, using npm-modules, transpilling and minifying to one single .html-file:
  • [x] Setup npm
  • [x] Setup eslint to promote a uniform code compliance b8afaeb
  • [x] Setup basic webpack workflow (transpilling code, import/export for external files, minifying and code optimation, HMR for React components) 60cbde5 97a5220 a5df914
• [x] Document the new system with a How to for adding new designs with this approach 3ecb07b
• Rewrite and transform all designs to react components (dropping jquery for React)

I will address these things in the next days. 🎃

[choyiny]

I don't have much experience with node.js, but is it good practice to store styles inside the html tags? Wouldn't it be better to create a new css file storing everything in it?

Also related, #14

[calvinrbnspiess]

I think it is a tough question to answer whether using inline styles or plain CSS files is a better practice.

I would say we can talk about different factors:

• performance
• maintainability, flexibility
• personal preferences

Maintainability can be influenced through a build pipeline (CSS-preprocessors, webpack workflow) that allows you to split your styles into files or to use variables in your CSS stylesheets, etc. which means they depend on your preferences. But that's not the decisive point. These tools can kind of arrange to your preferences. So, unless you want to improve and optimize performance on your site and you are literally fighting for milliseconds, it's more a thing of personal preferences.

Theoretically, there are advantages for both techniques. When the browser renders a site the first time with an external CSS file, the rendering of the DOM will be delayed until the CSS was loaded with an additional request which takes time. On the other side, it is easier (presumptive) for the browser to cache these external files. But an advantage of inline styles is the fact that the browser engine does not need to select and interpret the different CSS selectors, but rather can just apply the inline defined styles for only the element. When it comes to larger sites with a lot of duplicated styles, inline styles are in disadvantage again, because the size of the whole document grows proportionally. Here it would be better to write the styles only once with traditional CSS.

You see that it is pretty hard to answer this question. Presumably, the best solution would be a mix of the different techniques. But as I said, as long as you don't optimize a site for performance, the difference of a few hundred milliseconds does not matter. It's more a personal choice. With my proposed setup it will be possible to mix these although I would personally go for inline styles when you are using React because you can write everything in one language. Also, you can use javascript logic inside your styles like variables or functions to generate dynamic styles. And that's a great thing because you do not need CSS-preprocessors (like sass or less) anymore and have more possibilities.

Some interesting blog posts on this topic: https://developers.google.com/web/fundamentals/performance/critical-rendering-path/ http://stackoverflow.com/questions/8284365/external-css-vs-inline-style-performance-difference http://stackoverflow.com/questions/26882177/react-js-inline-style-best-practices https://gomakethings.com/inlining-critical-css-for-better-web-performance/ https://ctheu.com/2015/08/17/react-inline-styles-vs-css-stupid-benchmark/

[choyiny]

That's a really nice explanation, learned a lot! Look forward to your react based approach, tell me if you need any help from me.

[choyiny]

I've made you collaborator so you can take charge of the js branch.

[calvinrbnspiess]

I'm happy to announce that I completed my work so far. I implemented a reliable Webpack workflow and a new way to write designs with React. You can see a running demo at https://vailfire.github.io/afullstop/notaperiod/. Please read further details at my updated CONTRIBUTING.MD. I also experimented with a continuous integration using Travis CI, to automate builds and decouple them from manually building and pushing via git. Sadly, after spending nearly a whole day on investigating a suitable approach, I dropped my tries due to the too complex workflow that would have introduced too many edge cases where the continuous integration could fail. Perhaps it is possible to setup continuous integration easier with a project reorganization that would split gh-pages and source in different repositories. As long as we do not have a CI Job, we need to install Node.js on our development machines to build the project ourselves using npm run build.prod. Because of that, I also had to change the directory structure. The source needs to be in the same branch like the build for gh-pages and should be merged from the js branch to there. Now, the next steps are to convert all designs. I hope my new approach appeals to everyone. 😃