Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Latest commit

 

History

History
84 lines (60 loc) · 8.05 KB

2017-08-02-why-react.md

File metadata and controls

84 lines (60 loc) · 8.05 KB
title author image tags redirect_to
Why react though?
herflis
/img/posts/tw_sn_react.png
ui
front-end
reactjs
controls
components
view controls
field controls
forms

One of the key points of developing sensenet 7+ was how can we provide nicer ui for our end-users and a more accessible dev platform for the front-end developers at the same time.

We could stay with the old asp.net solution or create a custom no-framework one but we ended-up using React and Aurelia. In the following post I try to sum up the whys and hows behind choosing React.

Main goals

Working with the past versions of sensenet was not always easy. Especially when you wanted to change the ui. This was one of the key improvement points that we've detected and defined it as one of the main tasks for the development of future versions. We wanted to pimp up the ui anyway, so it was also important for us to find a solution for building a new admin surface and creating other building blocks of the public ui easier and more effectively.

We wanted to reduce the learning curve in the first place. In the old version of sensenet the building blocks of the ui were customizable to the smallest details which was great, but it was also the main reason why the customization was a huge work. There were html pagetemplates for the skeleton of a page, there were ascx views and xslt renderers displaying the components and js and there were css source files not to mention celltemplates, fieldcontrol templates, etc. As you can see it is at least four different technologies and all these things were stored in separate places in the repository. It was not easy to see through what, where and how should be customized. So it was clear that the front-end development should be unified.

On the other hand it was an important need from the start that if we rewrite the whole ui and everything that is related, the new solution should be componentized, testable (and tested), easy to deploy, accessible and should meet the industry standards, because it is a must if you want to be not only a simple cms but a development platform too. The no-framework solution was rejected very early because of the huge work. On the other hand there are tons of frameworks on the market which were potential options to fulfill our needs. So we just had to try them out...

It's not all about the hype

Hype train

Our selection may seem a bit ad-hoc but we tried to check out the most popular frameworks. We're working on a development platform so it was clear from the start that the chosen framework should be futureproof and a one with a great community. We've agreed to try out react, aurelia, vuejs, angular and angular2+ with building a todo app with them upon sensenet 7. Not all of them was evaluated by me, so I will reflect only on those that I've tried and just for a few words because it's more important why we've chosen React and why not Angular for example.

Angular2+ seemed a perfect match at the beginning because it's written in TypeScript and we love to write our stuff in TypeScript too, but at the same time it was a bit more difficult to learn it than the others and however it's not likely to happen again, Angular was completely rewritten once and we had to choose a long-term solution.

Vuejs is easy to learn and easy to use if you want to build a small project. But it was not really recommended for large scale apps and it has unfortunately a smaller ecosystem than the others.

(We've also built and improving continuously a control lib for aurelia, maybe @gallayl will tell us in another post why he chose it and what experiences he had with it. 😉)

So why React exactly

  1. Simplicity
    • It will take more time to learn the best practices but its learning curve is quite steep,
    • It's Javascript-centric which empower its simplicity,
    • Easy to add new features,
    • Tons of 3rd party libraries to use.
  2. Virtual DOM
    • Fast rendering,
    • React is not a real framework but 'view layer only' fits our needs in most of the cases.
  3. JSX
    • Javascript-centric design
    • Easy to learn, easy to read
  4. Redux
  5. Tooling
  6. Ecosystem
    • Great support and community.
  7. Non-web stuff
    • It's not part of the scope yet but React Native or next.js look promising when we talk about native rendering.

All that glitters is not gold

Working with React and TypeScript is not always as easy and fun as it sounds. Since we decided going along with TypeScript in our other projects it was clear that this one will be written in TS too. To be short unfortunately not all the above mentioned great stuff can be used (easily) if you want to stick yourself to the rules.

Webpack could be also the bad guy sometimes but it is maybe because we are not so experienced in it yet.

The results

React todo app

At the end we've made a control package, sn-controls-react with the basic view and field controls. It's open-source and since it's not finished feel free to add or modify it yourself. We are continuously developing it so we hope that it can be used as the base of sensenet's new admin surface and public ui in the near future.

It is built upon sn-client-js that provides the API and lets us manipulate the sensenet Content Repository. It also uses sn-redux which is a set of redux actions and reducers for sensenet Content management features. sn-controls-react has an ultra flexible mapping based on sensenet CTD's and FieldSettings which provides us Content management surface (create, edit, browse) generation. And last but not least it is built with react-materialize so it meets the standards and is customizable in common ways.

We are open and want to build a great community around sensenet so your opinion is super important to us. Please try, review and comment our work and help us make the world a better place! 😻