The following is unclear to me. So far, I don't see lose Reactjs components embedded in views, but only in Single Page Applications.
I was wondering if one could use Reactjs in a Laravel application in combination with the blade template engine? I have a Laravel project and I like the way ReactJS binds to the DOM. But I do not need an entire JS SPA.
So is it possible AND a good practice to use different ReactJs components loosely in blade views? For example a React table component and a header message component, that also are able to communicate with each other.
There is a package that does just that.
However I would argue it would be a better practice if you separate the front-end and back-end completely. So you can use Laravel to serve the data using REST API endpoints and then display everything using a React app.
This way they will be loosely coupled and if you ever want to swap out one for the other (e.g. swap out React for Angular) then it would be a lot easier as your api endpoints wouldn't have to change at all.
EDIT: Some benefits of a headless CMS (taken from pantheon.io):
By shifting responsibility for the user experience completely into the
browser, the headless model provides a number of benefits:
Value: future-proof your website implementation, lets you
redesign the site without re-implementing the CMS
Sets frontend developers free from
the conventions and structures of the backend. Headless development
not only eliminates “div-itis”, it gives frontend specialists full
control over the user experience using their native tools.
Speeds up the site by shifting display logic to the client-side
and streamlining the backend. An application focused on delivering
content can be much more responsive than one that assembles completely
formatted responses based on complex rules. Builds true
interactive experiences for users by using your website to power fully
functional in-browser applications. The backend becomes the system of
record and “state machine”, but back-and-forth interaction happens
real-time in the browser.
Lets say you also want to build a mobile app using React Native that would use the same underlying code base as your React web app. If you have a decoupled CMS, so your backend is only serving data then you can make calls to this same backend from both your web app and mobile app without worrying about content types, response formats etc... In-fact, with React Native you can use the same React codebase for the mobile app along with the web app and you would only have to change some views around.
It's a great way to re-use your code with better modularity and seperation of concerns.
Related
In the last few years, I’ve been working with an old fashioned stack, but pretty effective for my use case. The stack was Node + Express.js + Angular.js 1.x.
Basically, the backend made the rendering of the view (via dot.js or Handlebars, any template engine) and then, in the Frontend side, the Angular app was mounted.
The use case needed to be SEO friendly, so the content must be generated at the backend and served directly. Also, the UI has its functionality, forms, etc. It’s not just dummy text.
Currently for a new project with the same use case, I want to update my stack (using SSR aka server side rendering) where the app does not need to be a SPA (single web app). The base stack is still the same (Node + Express.js) and the only thing I want to update is the frontend library / framework.
I am looking for a framework / library with a big community and an easy way to share component and codebase across project. That’s why my first thought was React.
The first thing I found was Next.js and while I was reading and investigating, it goes beyond what I need. It is a quite big framework that has too much stuff I don’t need and I do not want to add overhead to my application and I cannot customize it as I desire.
I continue researching and I found an express package called "express-react-views" that is a template engine for express but it does not allow to mount the React application at the client side.
Browsing through the Github issues of the package, I found many people asking for these and they all end up being answered that Next.js was the way to go.
My doubts / concerns are the following:
Is React the right tool / library for this use case?
In case of not being, what do you recommend?
Being the right one, is there any package / tool on top of React and Express that helps me out with SSR that allows me the customization I need?
I don’t want to rely again in old or antique tools like jQuery or Angular.js 1.x because the maintenance and code sharing across projects is complex and annoying.
The easiest solution, without going deeply into Next.js, is using the native React feature ReactDOMServer:
https://reactjs.org/docs/react-dom-server.html#reference
It's actually pretty easy to use, you just serve the HTML as a string and mount your React App Client Side if you want then to handle requests with React Router.
I am a Fullstack web-developer which also wants to create SPAs (single-page-applications). So I was wondering what is the best way for the client (browser for example) to communicate data with the server without the page reloading or having multiple pages for different parts of the website? I want to create dynamic websites as well as use that knowledge for mobile web apps later on. And instead of the old way of sending data and returning it with a response, what could be a more dynamic and better way of doing this?
It can be reached in many ways but I would recommend you to take a look to websocket protocol. If you want to build it from scratch, socketio could be a good option. If you want build it with a framework, there are some of them that use websocket, for example feather.js, for reactive rest apis, or meteor, that is more powerful and complex.
I recommend you use Angular 6 where you will be able to use component-based application, each page or part of the page is denoted by a component, you can then bootstrap your app to integrate all components for dynamically built app, it does not require page loading (post-back loading). angular 6
For web development React or Vue seem to be a must have framework. Currently I just got some experience with NodeJs and Handlebars.
I know Handlebars runs a server side rendering, Vue and React run a client side rendering. Using Vue or React makes reusable components possible. Using a server side template engine requires a base layouting.
Let's say I have a website / webapplication with some routes. Why should I use Vue for HTML components instead of Handlebars HTML?
What I learned so far is that whenever I can
improve my SQL statement, do it before manipulating the data by code
do something at the client that can be done by the server, do it at the server because it has more power
Everyone is using Vue or React now, why should I leave the old structure and start outsourcing the code to the client?
I believe your question is more tied to the concept of server-side rendering and client-side rendering.
Server-side rendering has a few important points that you should consider when evaluating a problem:
Is faster to render the page in the server than in the client
It is much better for SEO(Search Engine Optimisation), since the crawlers can craw the entire page. Since some crawlers are not
evaluating/running javascript, a SPA(Single Page App) will probably
result in an empty page. Even though Google has improved quite a lot
with SPA SEO, server-side rendering is still the best option.
Client-side rendering, using SPAs, has different advantages:
Is much better to manipulate and maintain user state in the client-side, since you can have your webpage broken down into
components.
Faster interactions/page changes after the first load, since, in most cases, the entire app is loaded at once in the first request.
So with that in mind, you have to consider what you want to do. If you are building some website that reflects a more page-like structure, like a news or blog, server-side rendering is probably the best way to go.
On the other hand, if you are building a full-blown application that has loads of user interactions and state management, client-side rendering (or SPA) could be the best option.
There is no reason to outsource your code to the client-side without evaluating your problem first. That really depends on the problem you are trying to solve.
May I refer you to this article. As you can see it's not all black and white. From the cited article ..
Server-side pros:
Search engines can crawl the site for better SEO.
The initial page load is faster.
Great for static sites.
Server-side cons:
Frequent server requests.
An overall slow page rendering.
Full page reloads.
Non-rich site interactions.
Client-side pros:
Rich site interactions
Fast website rendering after the initial load.
Great for web applications.
Robust selection of JavaScript libraries.
Client-side cons:
Low SEO if not implemented correctly.
Initial load might require more time.
In most cases, requires an external library.
However, there are frameworks that do universal rendering such as next.js and nuxt.js (built around react and vue, respectively) that can leverage the powers of both the client and the server so you can have the best of both worlds. This usually involves sending the fully rendered application in the initial payload from the server to the browser and then loading the application code browserside afterwards.
Our entire codebase is built on just express, we want to build it out and in the process convert it to a single page application. As of now I am opposed to rewriting the code to work with a framework like Angular, or React, to accomplish this.
Thanks for reading.
Are you sure a SPA web application is what you really want to achieve?
If you are, then the answer is Yes: you don't need a framework for any SPA or any other frontend purposes.
A SPA usually consists of following parts:
Client side routing (eg HTML history mode)
Client side templating (see Smashing Magazine article for some examples)
Retrieving the data (eg via Fetch API or Axios
So, using these technologies, regardless of your backend technology, you can create a SPA with Vanilla JS. Actually, what you use at your backend has little to no affect on your SPA.
However, depending on how big your application is or how much features you need, you might end up using one. Frontend frameworks are designed to make your life easier.
If you are looking for a framework with an easy learning curve, I strongly suggest Vue.js. You can even get started without installing or transpiling anything locally.
yes, you can - depending on the complexity of your application you may end up transitioning to React, Angular, or another frontend framework in the future depending on your needs.
here are some resources:
https://tutorialzine.com/2015/02/single-page-app-without-a-framework
Todo in different frameworks (for comparison):
http://todomvc.com/
Angular vs Vue vs React:
https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176
If you're going for a real single page application you should be able to continue to use express. You'll find yourself jumping through some hoops though and using React/Angular would be a better approach because of how you could move forward with it in the future with no limitations.
I have a large, globalised web site (not a web app), with 50k+ pages of content which is rendered on a cluster of servers using quite straightforward NodeJS + Nunjucks to generate HTML. For 90% of the site, this is perfectly acceptable, and necessary to achieve SEO visibility, particularly in non-Google search engines which don't index JS well (Yandex, Baidu, etc)
The site is a bit clunky as complexity has increased over time, and I'd like to re-architect some of the functional components that are built mostly using progressively enhanced jQuery as they are quite clunky. I've been looking at React for this with the Redux implementation of the Flux pattern.
Now my question is simply around the following - nearly 100% of the tutorials assume I'm building some sort of SPA, which I'm not. I just want to build a set of containerised reusable components that I can plug into replace the jQuery components. Oh, they have to be WCAG AA/508 accessible as well
Does React play well with being retrofitted into websites and are there any specific considerations around SEO, bootstrapping, accessibility? Examples of implementations or tutorials would be appreciated.
You can mount react component to any DOM Node on your page, so it makes it easy to insert components in statically generated content.
Most of search engines like google would wait for js files to load before they index the page so it will index a page with react component perfectly fine. However if you want to be 100% sure that your page rendered correctly by all crawling bots you have to take a look at react server rendering. If you already use NodeJS for a backend it should not be a big problem.
I never encountered with that kind of problem but my best guess would be to use ReactDOMServer.renderToString to render component on the server and then replace a node in your static html layout. The implementation would depend on you template lang you use. You can use something like handlebars to dynamically create halpers from React Components. So in your static html page you would be able to use them as {{my-component}} But it's only my speculations on that subject, may be there is more elegant solution.
Here is the article that could help.
You'll be happy to know that this is all possible through something called isomorphic javascript. Basically you'll just use React and jsx to render HTML on the server which is then sent to the browser as a fully built web page. This does not assume your app is an SPA, rather that you'll have multiple endpoints for rendering different pages, much like you already have probably.
The benefit here is that you can use the React/Redux architecture but still allow you site to be indexable by crawlers, as requests to your app will yield static pages, not a single page with lots of JS to make it work. You're also free to gradually refactor by converting your Nunjucks rendered endpoints to React one at a time, instead of a big jump to SPA land.
Here's a good tutorial I found on making isomorphic React apps with node:
https://strongloop.com/strongblog/node-js-react-isomorphic-javascript-why-it-matters/
EDIT: I may have misread your actual desire which is to inject React components into your existing web pages. This is also possible, you'll probably want to use ReactDOM to render your components to static markup, and then you can inject that markup string into your Nunjucks via templating.