I know what angular.js is and I even had a question about it #Why use AngularJs in frontend if Laravel is already used as backend?.
but recently I started to read about React.js and from its site (its the V in the MVC) which is exactly what am after "handling the view and nothing else".
for me, I think Angular.js as an MVC framework was made to be used with something that is built with JavaScript from start to end like Node.js
and it seems like an overkill when used with something like Larval, where I simply need something to handle the frontend and nothing else + Angular have 2 main drawbacks
with the latest news about a new version that won't have back compatibility with the current version makes me even feared to start learning it just to find that more or less every project out there is using the old version which mostly is true.
angular renders the whole dom if anything got changed which again is an issue for big projects.
so based on the above, plz note that I want to learn/use JS solely to enhance the user experience not to build another Gmail or Facebook and so my question is,
could React.js be used with Laravel to handle the view and do everything Angular was going to give, or I have to use Angular liked or not?
could React.js be used with Laravel to handle the view and do everything Angular was going to give?
No
React is just for views. React components are stateful components with some really clever rendering stuff happening behind the scenes. To build a fully functional front-end app, you'd need to tie in some other code (or write it yourself).
React works well with Facebook's Flux architecture. I would suggest looking into that to learn how to manage the state of your react components.
What's key to understand here is that Flux and React are not parts of a large front-end framework. React is a library and Flux (as provided by Facebook) only provides a Dispatcher. The rest is up to you to implement. There are some pre-existing implementations you can look at if you need some help to get started.
What I like about flux is that it allows me implement things the way that fits my application best. React takes care of the heavy DOM lifting and is very easy to learn. Compared to Angular, I don't have to learn arbitrary conventions and gigantic APIs of a huge framework.
Related
My question is, can I use the react framework with #spartacus storefront? this is because our frontend application is developed in React and we want to use #Spartacus storefront to leverage advantages like decoupling front-end and Hybris build ..etc. but as it is developed on angular I am not sure whether it supports other frameworks like React within it.
There is some effort in making possible using web components as cms components, so you could use any technology to author them (including React), but it's still in the experimental phase (but works already).
More info is available in the docs:
https://sap.github.io/cloud-commerce-spartacus-storefront-docs/customizing-cms-components/#using-web-components-as-cms-components-experimental-support
And here you can find some example POCs for React, Vue, and Svelte:
https://github.com/dunqan/react-cms-web-component
https://github.com/dunqan/vue-cms-web-component
https://github.com/dunqan/svelte-cms-web-component
Spartacus needs Angular. So, I would say "NO", unless you want the complexity of integrating Angular with React.
We have huge enterprise application written in angularjs.
Now we have to migrate to angular, so we have ruled out an option of hybrid approach angular suggests using "ngUpgrade".
So now we are creating a new application in angular, which means we have 2 applications "angularjs(old)" and angular(new).
So to switch between these two applications can be done without refresh using angular-spa.
I was trying to find if there is another framework, where navigating between two apps happens without refreshing(without refreshing entire page by navigating to new html).
Possible solution:
Use a new Angular application as a wrapper, then just use iframe to show the application you want depends on the context - old or new. The issue you might face is changing the iframe, but I guess you can use postMessage to communicate between the apps.
A bit more sophisticated:
Use Angular Elements to create your hybrid app.
I really recommend you to watch Erin talks from the last Angular connect about how Google made the migration from js to Angular.
I've recently tried the micro-frontend architecture described here:
https://www.martinfowler.com/articles/micro-frontends.html
Each app on different code repository, runtime build and quite easy to implement. Take a look :)
Regarding of what backend you use to power the API behind a React app (Ruby on Rails, Node.js/Express, Java, etc), what are the consequences of making the frontend React app separate repository?
I like the idea of having my ReactJS app separated from my backend API code, just want to understand the pros/cons of going with this approach.
pros
front-end devs doesnt have to get familiar with backend
You can choose not to show your secret recipe.
can upgrade and deploy one without the other
Code Reusablity
Lazy loading for better UX
I actually dont have any cons to tell about this. it's just that i feel right developing apps like this. installing npm packages in RoR felt so wrong.
more Pros -
You new separate UI can link to more backends than 1 - think centralized UI for disparate components
Like Angular more, bang you got it
Like React more than Angular, bang you got it
Cons -
Needs added work to setup CORs
You will probably have to cookup secret sauce for pagination, serialization (i.e tied together even though separate) - not a problem if you follow a standard anyway
Need to have a long deep thought on behaviour when the backkend is down
Need to wrap brain around pull vs push
You now have 2 diff OS stacks & TCP stacks in the picture to increase your work on sys admin patching & understanding latency between the components
wrap brain around state & its management
IMHO separating the UI is worth all the cons given the pros outlined here & by Shan
This is more of question of if it makes sense to use Reactjs in my instance. I have an application that generates html serverside. I can not use any js based templating solutions serverside, it is a java/jsp solution blackbox.
Since the markup is already defined I am weary of using JSX to duplicate all the template logic currently only on the serverside. What is typically the best approach to integrating reactjs in to an application like this.
What will be the real advantage to using reactjs for me in this situation. Most of may app will continue to be rendered serverside go forward.
Obviously React is not designed to be used like this; but you could still do it.
Long story short: If you want to build something more complex in front-end you should do it; if you only want to get advantage of JSX templating instead of jsp, it's just a big overhead.
Advantages:
You will be able to step away from standard jQuery approach of handling javascript in .jsp.
You will get all the benefit of a client-side framework, so you are able to handle more complex scenarios in front-end as you would do with standard javascript.
You could hide some business logic in the java side (servlets) and making it available to React world.
Disadvantages:
Probably it's a pain to prepare the development environment mode (webpack, hot-reload, etc.); e.g. you'll need to recompile the jsp on the fly on every js change.
You can't use client-side routing (so you'll have like one SPA per page).
Probably it's really hard to make server side rendering work (for the React part)
what are the advantages of using 2 MVC architectures(frontend and backend) in same project. AngularJS and Spring MVC.
Without using AngularJs, can I update single div data without loading the entire page? Is AngularJS responsible for updating single <div> data out of multiple <div>s without loading entire page? If so, please explain in detail.
Once you have a single-page application you have to make sure all the different parts of that application are consistent, that's what the MVC/MV-Whatever in the front end is doing for you. That's not an issue in an old-school web application because the relevant state is regenerated with each request, but once the updates are coming in bits and pieces then different pieces of the front end need to be coming from the same model and that model needs to get updated consistently.
Obviously you can implement div updates with raw JavaScript, you don't need frameworks just to do AJAX. The JavaScript frameworks are written in JavaScript, after all. The frameworks and libraries do make things easier by doing things like papering over browser inconsistencies and providing convenient and useful features (like databinding in Angular).
The server-side MVC does become less complex and involved than it was in the old-school web application, you have less POST-Redirect-GET going on, the front end is more in control about what it is asking for. The front-end application is decoupled much more from the server-side because that whole server-side view layer of JSPs or Facelets or whatever is greatly reduced or just missing, instead you have services supplying JSON over HTTP and there is a much more limited, well-defined contract.
You can update a single element of your page without using AngularJS. As an alternative, for example, you can use JQuery.
You should wonder for the best approach for your project. This answer explains very well the differences between this two approaches.
As an aside note, AngularJS is not exactly a MVC architecture. Instead, the community has decided to call it MVW (Model View Whatever). Check this source for more details.