I'm an old web developer, i'm used to html, css, js (jquery) and using a server side language like Java, Cold fusion or PHP.
Now for the life of me i can't find a good explanation or a how to get started. It just doesn't make sense and i've spent the last 3 days watching tutorials and reading books. This isn't to complain, but to ask a favor. Someone please explain to me how this architecture is setup. In the past, you would have an html file and inject some placeholders which would be filled in by your server side language.
What's the structure now? I have create a Ubuntu server, i have installed NodeJS and it's associations, i created a reverse proxy and installed nginx as my server. PM2 is my process manager for NodeJS apps. Am i on the right track so far?
If so, where does reactjs, reduxjs, babeljs, what is webpack for npm? What is my next step, i'm so confused that i don't know what all of these things are. In particular what is the difference between reactjs, redsuxjs and bablejs and any others, are these all just front end libraries or? What's the npm webpack. Then there's redux and react-redux, what? Thanks for the clarification.
My goal
I want to learn how to make a single page application and takes advantage with as much of bootstrap as possible. I thought react would be the way to go but i'd really appreciate some clarifications and not just a copy-paste from their website descriptions. Thank you guys/gals.
First of all, there isn't a short answer to your question. Each of the subjects can be delved into for days, weeks, or months to understand and master. I will try to use metaphors for all related topics in your question.
Q: What is Babel and why do I need it?
JavaScript has evolved over the past few years. A lot!. JavaScript today has so many new words and sentence structures that old browsers simply can't understand without a translator. Babel is that translator. Modern browsers today (Chrome, Firefox, Edge, Safari) can natively understand most of that modern version of JavaScript, or as cool kids call it ECMAScript2015, or ES2015, or ES6, etc.
Even so, ES(JavaScript) is constantly evolving. New features are being added in stages and babel is keeping up with these stage features, literally translating all these new features into plain old JavaScript that all browsers, regardless of age, can understand. You can play with babel and see what it does here: https://babeljs.io/repl/
Q: What is React?
React is just one of many modern front-end frameworks to help you display your data in an efficient way.
If IKEA produced LEGO for developers, it would be called React. React let's you create LEGO blocks (called components) and put them together to create an app. React components can be purely presentational(or 'dumb'), meaning they will simply return some HTML, or they can be 'smart'. Smart components can have something called a state.
If we go back to the LEGO analogy, the state would be the engine in a LEGO Technics set. If a component was a plain old LEGO car, it would need some outside help to get it moving forward. You push the car with your hand and it moves forward. With a smart component, or a LEGO technics engine, your LEGO Technics car can change its state from resting to moving on its own when the engine starts, intrinsically pushing the car forward from within. So whenever the state changes, your car REACTS and changes. The same goes for a component. React will watch for changes in the state of your component and whenever there's a change (usually triggered by a user event) the component will update. React components can be written in plain old javascript, but ES6 is encouraged, and makes your life as a React developer a lot easier. Thus, you will need a translator, like Babel, to make your React app understandable in the browser.
Q: Redux?
Ok, I will simply stop you here and tell you that at this point you don't need Redux to create a React app. Redux is a library that can be used in combination with any framework or on its own with vanilla JavaScript. What Redux does is give you the ability to abstract your application model or data away in something Redux calls a store. A store can be anything, an array, an object, literally anything. Redux's job is to update that store anytime it receives and action.
Let's imagine Redux is a living person called John. John is given an empty cup (the store). Each time John is told 'pour water', John will grab the cup and pour some water in it. The 'pour water' command is our action. John can listen for other actions, for instance 'empty cup'. Each action goes through a processing unit - John's brain (the reducer of the actions). If John was brainless, he wouldn't be able to execute any of the actions. When John receives a 'empty cup' command he throws the water away. You can teach John however many actions you want, and you can give John a different store to execute those actions on. The important takeaway here is that John has a store(the cup), a reducer(the brain) and is given some actions to execute. So the action, goes through the reducer and based on what the reducer decides, it updates the store. So in JavaScript terms the reducer is a function, which takes an action and returns a store. The action is a plain javascript object, which has a type property ('pour'), and it can also have some payload ('water'). So basically you can tell John, 'pour water' in the cup, where pour is the action type and the payload is water.
Q: React-Redux?
Think of react-redux as a scotch-tape that lets you fuse react and redux together, so that each component can send an action to the reducer, and each component can have access to the store.
Q: Webpack?
So with the above example we already have several libraries. Babel, React, Redux, React-Redux, and who knows how many other libraries, assets, files and what not you will need in your project. Probably what you are used to is importing each of them in your index.html using the script, image, link tags. Well, overly simplified, webpack does that for you! Whenever some module in your app depends on another module, asset, or anything else, webpack will recursively look for all dependencies and put them together in one file. You simply import that one file in your index.html and you forget about it. Webpack can do many other things for you, but that's the gist of it, hence why it's called module bundler.
Whew, that's about it. You are a real hero if you got this far, and I admire your patience.
P.S.
A really great (and funny) article to help you get up to date with all these libraries and frameworks is this one:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
As you mentioned that you have worked on HTML, CSS, JQuery and JAVA. It will not be difficult if you understand the need of Reactjs and Redux. If you are using plain javascript or jquery. It will be difficult for you to maintain the code as the size of application will increase. With the help of react js code will be easy to maintain at client side.
Example:
React
Suppose you are creating an e-commerce application which include products, selected product description, shopping-cart, stock-availability of product. If your application is single page. Page will not refresh. You can use react to implement this e-commerce application. You can create components like ProductDetailComponent, ProductDescriptionComponent, ShoppingCartComponent, StockAvailabilityComponent. You will inject all the component in the main component. In this way your code will be more modular at client side. Suppose ShoppingCartComponent needs PriceComponent, BasketComponent. You can use these component inside ShoppingCartComponent. In this way you have component inside other component. If you need to use ShoppingCartComponent in other pages. You simply need to import that component in that page. In this way you can reuse existing component.
All the component will maintain there own data in this way component will not be tightly coupled and can be use at multiple places in our application
Redux
Redux is not related to React. You can use redux with angular as well. Benefit of using redux is you want to share some contextual data across component like user information you can use redux so that user information will be available across component. No need to make additional servder call to get that data. So redux is providing client side caching.
One more benefit of using redux as store is that we can maintain single copy of data. If any component change the data all the component will get notified that data have changed. In our shopping cart example product selected by user can be maintianed in redux which can be used by all the component.
Data sharing between parent to child component
You can pass data from parent component to child component with the help of props as in case of ShoppingKartComponent you need to pass some data to Price component you can use props. You can also pass function as props to child component which child component can call to notify parent component with updated data.
Related
What is the best way to persist user-generated data with NodeJS, Express, and MongoDB?
I'm building my first web-app using this stack (with bootstrap HTML/CSS and JS for the frontend) and I've realised that I need a data-binding solution. I'd rather avoid a complete rebuild of my front-end so it seems like React will be the best option, but I'd rather find out now if I'm missing something obvious.
The app will allow users to create 1-n documents, generate 1-n new components within them, and edit 1-n content-editable elements within those components.
I'm at the point where I've built the server, db, and frontend and the users and documents persist, but the components and their content does not.
The functionality I would like is that, when a user generates a new element or exits the contenteditable area of that element, any changes they have made will persist. I'd like to achieve this without a bazillion API calls.
Any assistance appreciated.
You may create page description in markdown and then render it to react components.
For example you can check https://www.gatsbyjs.org/ plus Remark Custopm blocks plugin - https://www.gatsbyjs.org/packages/gatsby-remark-custom-blocks/
I’m new to React, and I have trouble with finding best solution for my app.
My current (Node.js+Express+Handlebars) app has one main menu with place where I render HTML received from AJAX request made after click on menu element. Then all actions inside this element are done by proper JS script. I wanted to improve it by using React, but I have problem with permissions management.
Currently, after authentication, handlebars receive list of files which user should load and render it as src in element. If user has access to only 5 of 20 modules, he can access only proper JS files. Also, he can’t access HTML he don’t has access to.
How to manage it in React? I want to have one interface for all users, but I don’t want to store logic for all components accessible for every user. I was thinking about something like AJAX loading components for React, but how to manage it?
Is it even possible? As I understand (maybe wrong), all React components are compiled from separated JSX files to one main.js, so is it possible to add separate files with other components?
I believe that the issue that you have encountered is a crucial step on the long stairway of making something great. The solution to your problem is the balance of all the present factors and consolidation of them to cooperate on a mutually beneficial basis. I hope that solves your problem
My issue: For my thesis I am creating an auction site. I have an admin panel in which I would like to have some configurations so that an admin can specify that if there are 10 days before the end of an auction some components should be displayed in different ways, some should be not visible at all etc. That’s what I call dynamic presentation.
My question: Right now I am working on architecture and wondering if SSR can be helpful in any way? I am already aware that it can shorten download time of some collections from my database even by half, but I am wondering if there is any way how it can be helpful with dynamic presentation itself?
What I already know: I have read all about advantages and disadvantages of ssr or universal rendering in react. Now I am only wondering if it can be in any way helpful with dynamic presentation or it won't matter if I choose SSR or CSR.
Small side question: I don’t have the whole architecture ready yet. What I know is that I would like to have a database, one separate app for an admin, backend and frontend (either ssr or csr). My first thought on how to manage this dynamic presentation was to store some rules in the database. Then the rules could be configured in admin app should an admin want to change anything. The rules should be send to backend and calculated with some additional data from frontend. Then backend could send some flag to frontend indicating which components to display etc. In theory I could move calculating to e.g. NodeJs server should I go with SSR. What I'm wondering about is; can you think of any better way to handle dynamic presentation? What I am most afraid of is numerous ifs in the fronetend. I would like to have some more elegant solution but I have no other idea so far. For some time I thought about a scoring system but I believe it would be too complicated (instead of sending a flag, send a score and frontend will display correct things based on the score). Also it wouldn’t solve the issue of ifs on the frontend.
I am aware that on StackOverflow questions which can be answered rather than discussed are preferred but I am really stuck and would appreciate help.
Basically SSR can provide some speed on your page because all of your data will not be trying to be fetched when the react script will end with an API call. Data are fetched from database when page is requested and be passed to the component to render with the script.
Also another very basic advantage and the reason why everyone are going the SSR way is SEO. You cannot achieve SEO page with react CSR. This is because google bot etc will try and crawl your page without even render it. Is like trying to "view source" of a page. When you are in CSR the page has no content only the initial react divs empty. You need SSR to have data on the first request of the user.
SSR brings the data on the first request of the user until a reload. In the meantime react router fetches data from the api.
Let me know if that help you.
PS: also a helpful link https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8
I am building a sports data visualization application with server-side rendering in React (ES6)/Redux/React-Router-Redux. At the top, there is a class-based App component, and there are two different class-based component routes. (everything under those is a stateless functional component), structured as follows:
App
|__ Index (/)
|__ Match (/match/:id)
When a request is made for a given route, one API call is dispatched, containing all information for the given route. This is hosted on a different server, where we're using Restify and Sequelize ORM. The JSON object returned is roughly 12,000 to 30,000 lines long and takes anywhere from 500ms to 8500ms to return.
Our application, therefore, takes a long time to load, and I'm thinking that this is the main bottleneck. I have a couple options in mind.
Separate this huge API call into many smaller API calls. Although, since JS is single-threaded, I'd have to measure the speed of the render to find out if this is viable.
Attempt lazy loading by dispatching a new API call when a new tab is clicked (each match has several games, all in new tabs)
Am I on the right track? Or is there a better option? Thanks in advance, and please let me know if you need any more examples!
This depends on many things including who your target client is. Would mobile devices ever use this or strictly desktop?
From what you have said so far, I would opt for "lazy loading".
Either way you generally never want any app to force a user to wait at all especially not over 8 seconds.
You want your page send and show up with something that works as quick as possible. This means you don't want to have to wait until all data resolves before your UI can be hydrated. (This is what will have to happen if you are truly server side rendering because in many situations your client application would be built and delivered at least a few seconds before the data is resolved and sent over the line.)
If you have mobile devices with spotty networks connections they will likely never see this page due to timeouts.
It looks like paginating and lazy loading based on accessing other pages might be a good solution here.
In this situation you may also want to look into persisting the data and caching. This is a pretty big undertaking and might be more complicated than you would want. I know some colleagues who might use libraries to handle most of this stuff for them.
What I would like to know is, how do you built your web application? I'm really confuse as which method should I use for my project.
Already decided which technologies to choose.
1) Node.js and express as its Framework
2) MongoDB
3) React + Flux
But the problem right now, should I use method (A) or method (B)
Method (A) - Serverside rendering for HTML
app.get('/users/', function(request, respond) {
var user = "Jack";
respond.render("user", { user: user });
});
Method (B) - Clientside rendering for HTML
app.get('/users/', function(request, respond){
var user = "Jack";
respond.json({ user: user });
});
Method A will render the HTML from the server and as well as the data.
Method B will just respond the data that is needed for the client which is React.js, so that it could manipulate the data.
My concern, is which method should I use? most startups use which method?
Thank you.
It's not an either/or proposition.
React is a client side framework. You have to render on the client side. The question is whether to render on the server side in addition to rendering on the client side.
The answer? If you can, YES!
You will get SEO benefits and an initial performance boost by rendering on the server side. But you will still have to do the same client side rendering.
I suggestion googling "isomorphic react" and doing some reading. Here is one article on the subject.
http://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/
Well, it really depends on which vision you have on the modern web, and what you are willing to do.
Will you prefer to let your users wait, displaying a loader while data are loaded asynchronously, or will you prefer to keep your users busy as long as you can ?
Here are different articles that will help you clear your mind and be aware of the different advantages that you can have by doing server-side rendering, client-side rendering having multiple issues.
You can see this post from Twitter blog saying they improve their initial page load by 1/5th to what they had before, by moving the rendering to the server:
https://blog.twitter.com/2012/improving-performance-on-twittercom
An other article, this time from airbnb, describing the issues you can have with client-side rendering itself:
http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
There is also an other interesting article talking about client-side/server-side rendering, bringing a debate on when should we use / not use server-side or client-side rendering and why:
https://ponyfoo.com/articles/stop-breaking-the-web
And to finish, I can give you two more link more focused on react, and describing in which way server-side rendering should be helpful for your case:
https://www.terlici.com/2015/03/18/fast-react-loading-server-rendering.html
http://reactjsnews.com/isomorphic-javascript-with-react-node/
Now, about what you SHOULD do, it's a matter of what you exactly need to do, to my opinion, but basically, you can do both at the same time (client-side AND server-side), to have the best user experience.
This concept is called "isomorphic javascript" and it is getting more and more popular these days.
The simplest architecture is to just do dynamic html rendering on the server, with no Ajax, and with a new HTML page requested for pretty much any client click. This is the 'traditional' approach, and has pros and cons.
The next simplest is to serve completely static html+js+css (your React app) to the client, and make XMLHttpRequest calls to webservices to fetch the required data (i.e. your method B).
The most complex but ideal approach (from a performance and SEO perspective) is to build an 'isomorphic' app that supports both approaches. The idea is that the server makes all the necessary WS calls that the client would make and renders the initial page that the user has visited (which could be a deep-linked part of the application), a bit like option A but using React to do the rendering, and then passes control to the client for future DOM updates. This then allows fast incremental updates to the page via web-service calls as the user interacts (e.g. just like B). Navigation between different 'pages' at this point involves using the History API to make it look like you're changing page, when actually you are just manipulating the current page using web-services. But you you then did a browser refresh, your server would send back the full HTML of the current page, before passing control to client-side React again. There are lots of React+Flux+Node examples of this approach available online, using the different flavours of Flux that support server-side rendering.
Whether that approach is worthwhile depends on your situation. It probably makes sense to start using approach B (you can share the your HTTP API between mobile apps and websites), but use a Flux architecture that supports server-side rendering and keep it in mind. That way, if you need to improve the performance of initial page loads, you have the means to do it.