Xtykutl

We are planning to switch new technologies like react for my CMS project which is under development for 10 years.

Until now everything was simple and plain on the front end.

First include jquery.js then if necessary include the components and third party scripts, then code and dance with the DOM.

But now while trying to jump into a higher level of technology and different approach, things can easily get very complicated for me.

After spending more than 10 hours with React documents and tutorials I have a very good understanding about what it is and how it works.

But I realized that I am very unfamiliar with some popular concepts. I never used node.js, never used npm, babel, webpack, and may other many "new" things I have seen every where. I am face to face with these tools because of React and I am convinced that these are the inevitable for modern front end development.

Now the question

Our CMS runs on PHP and depends on MooTools heavily at the front end. Instead of a complete rewrite of a 10 years old CMS I just want to try new technologies partially for some cases. Decided to starting with React.

For the case I want to integrate ag-Grid to React also.

What I did not understand is that how to bring all these tools together.

I won't be able to use the simply include js way of react because of ag-Grid.

In the examples the code written has some JSX. Which means that we write JSX and run it translated for the browser to test if it is ok.

• Each time before testing do I need to translate these files?


• And more over if the files are translated does debugging become very
  complicated?


• Can babel make it on the run time? If yes is it a good practice.


• There are lots of file in the node_modules folder. Which of them
  should I include for production?

All sources on the net are very theoretical and assumes a knowledge. Need some guidance for best practices.

There are lots of questions and not a single step by step guide from beginning to production.

JSX is an extension over spec-compliant JavaScript. It is syntactic sugar for React.createElement(...) and is optional in React development.

React can be written in plain ES5:

React.createElement("div", { foo: "foo" });

Instead of JSX:

<div foo="foo" />

Or with helper functions like h that achieve the same goal, e.g. react-hyperscript.

The fact that there is PHP backend application doesn't prevent from developing React frontend application with JSX. This may require to configure React project to not use built-in Express web server and build client-side application to custom location, i.e. existing app's public folder. In case create-react-app is used, this may require to eject the project).

Each time before testing do I need to translate these files?

They should be transpiled to plain JavaScript (ES5 if it targets older browsers). They can be translated on every change in source files when client-side project runs in watch mode (conventionally npm start).

And more over if the files are translated does debugging become very
complicated?

This is what source maps are for.

Can babel make it on the run time? If yes is it a good practice.

It's possible to use Babel at runtime, and this isn't a good practice, even in development environment.

There are lots of file in the node_modules folder. Which of them
should I include for production?

The contents of node_modules doesn't matter. Almost all of them are development dependencies that are needed to build client-side app. This is the task for a bundler, which is Webpack in create-react-app template. It builds project dependencies to plain JS in dist folder.