We have an Angular 1.3 based webapp and would like to migrate it to React + Redux. What would be the best course of action, where we can have the Homepage as React, and the remaining as Angular, and slowly move one page at a time to React.
My major doubts are with respect to routes. Which framework should handle the routes?
Are there any other things that I should be worried about?
Alas, maybe my question was too open ended or was not worthy of an interest from any.
Was forced to use a reverse proxy setup with express (served on
localhost://3000) with cors being enabled.
Few routes (/, /page1) redirecting to a http-server serving the React app on port 3001.
And the remaining routes (/cart, /somethingElse) redirecting to a http-server serving the Angular app on port 3002.
This was just a dev setup.
In prod setup, the pages are being served by Akamai and hence was beyond the scope of the question.
I've written an article describing how we went about this in BigPanda - https://medium.com/bigpanda-engineering/gradually-migrating-from-angularjs-to-react-redux-a4a16585d3ff.
The gist is keeping the app wrapper in AngularJS, gradually replacing AngularJS components with React ones, and then at some point in the future when all components are converted, removing the surrounding AngularJS code and replacing it with React as well.
Related
I want to make partially SSR web application and looking for best solution for that. I need SSR for SEO and that will only serve dynamically rendered products pages - this will be handled by NextJS.
Other part of the app is only for logged users and I don't want anybody not logged to accidentally display it (but only users data have to be secure, if anyone access by a hack those restricted pages without any user data that's ok) - for that part I've already implemented React Router with proper redirections and few routes (it's using Redux too).
Whole project was made with create-react-app. Is there a way to easily combine those two functionalities? Do I have to move everything from /src to /pages? Maybe best way would be to serve them independently and just redirect to one or another using Apache configuration?
If anybody wonders about it - currently the best solution would be to use NextJS for all of it, cause Next provides a clean way to handle static pages, CSR and SSR alongside each other.
By the default all pages are static generated or pre-rendered with partial CSR, while using getServerSideProps method allows to handle SSR, without any extra configuration.
I am using React in my project and I have problem with client-side prerendering.
More specifically, it would be necessary to configure SEO
Which is the least painless way to prerender existing reactjs app wiht react-routes
Some examples I have researched:
Gatsby.js - https://www.gatsbyjs.org/docs/porting-from-create-react-app-to-gatsby/
Next.js - https://nextjs.org/docs#custom-document
Netlify - https://dev.to/joelvarty/prerender-your-spa-using-netlify-for-better-seo-3h87
React-snap - https://web.dev/prerender-with-react-snap/
Prerender.io - https://prerender.io/
Keen’s Server Side Rendered - https://medium.com/keen-studio/keens-server-side-rendered-react-wordpress-rest-api-boilerplate-bb58edb7cc0a
Razzle - https://reactresources.com/topics/razzle
React Helmet - https://github.com/nfl/react-helmet
Can anyone suggest what option I should choose that is the least painless.
I have headless wordpress as backend and reactjs client-side as frontend.
Or are there other faster options besides the prerendering?
Thanks.
IMO you really don't need to use a framework to achieve SSR if you want to keep control without turning your codebase into a blackbox and choose your own stack.
I created some boilerplate using Node Express. It supports:
SSR using StaticRouter on the server and BrowserRouter in the client
ES6 webpack transpilation + hot reloading both client and server and auto-updating browser
Redux, data preloading and client store hydration
https://github.com/kimgysen/isomorphic-react-setup
Last time I ran it, I noticed that I hadn't saved the favIcon in the public folder and perhaps there are some minor bugs that I will fix soon (I've fixed them in my projects but didn't update this repo because nobody looks at it anyway (lol!)), but what happens here isn't all that difficult to understand.
I created some basic SSR websites with it in a matter of hours.
I enjoy redux-observable to initiate server ajax calls before rendering the content (using forkJoin), but this is not included in the boilerplate (I haven't actually supported it since I uploaded the first time).
But in terms of setup, I don't really see a point in using a framework for this necessarily, it really isn't that painful / difficult to do yourself.
The benefit that I particularly like is that you don't depend yourself on the scope and dependencies of the framework. You don't get into trouble with things like 'the framework will support this feature or fix that bug in one of the upcoming releases'.
Although ultimately, it comes down to personal choice. So it's not like I want to downgrade these frameworks.
Note: The way Redux achieves pre-rendering is simply by adding Redux store (state) objects to the window object in the html that is sent back to the client.
Then at the client, the it initializes the stores with these objects.
So very simply, this is something that is easy to achieve, even if you decide not to implement any other SSR features.
to create server side applicantion with painless integration you can use my cli to generate a default configuration like create react app cli from facebook, https://github.com/ghondar/crassa
I am a little bit confused about front end frameworks. I read that if you used ng-route or react-router it would make your app a single page application, so does it mean if I don't use ng-route/react-router and instead used express for server rendering would the app still considered a SPA ?
To answer your final question, if you're serving bits of your site from different Express routes, then by the definition of a Single Page Application it's not a SPA anymore, no.
However, there's nothing explicitly wrong with doing that. ReactJs is a tool and a way of working with components. If you want to work with components, but you're more comfortable with serving your individual views from different server-side routes then just do that. Not everything needs to be a SPA. Once you're comfortable with the core of how React works from a mark-up/component point of view, you can start incorporating partial page renders and client-side routing etc.
I think you are not getting the point about SPA. Please read the following:
https://en.wikipedia.org/wiki/Single-page_application
When creating an app with create-react-app,there is only one index.html,does that means React can only handle one SPA at a time? What if I want to develop multiple pages? Should I create another SPA with create-react-app and then put them together after building each of them?
Update:
Parceljs can do that. here is docs.
You can use Parcel instead of Webpack (which being used in create-react-app) and it provide you zero config environment to develop web apps (using react or anything else).
Having multiple pages (instead of SPA) is not what most React environments had in mind [before - see update above].
You can have different page URL's using react-router or similar client side routing solutions.
If the concern is bundle size, there are solutions using webpack or parcel to lazy load each bundle whenever they needed or cache bundle (using service workers) and so on (Tree shaking, ...). (check Code Splitting in React Docs)
Other concern I might have in my brain is SEO, in this case you may find Isomorphic app (react server side rendering) useful which initialize first view of requested URL HTML and sends it to client, then client will load react and react will take control of UI. This will help Google (or other search engines) find your URLs fast and user experience in transitions between pages will remain seamless.
I am using angular-ui-router with my angular 1.3 app. I am looking to upgrade it to angular 1.5. What are the best options for routing in angular 1.5? Shall I continue with angular-ui-router or shall I move to something like angular-new-router. Please suggest. Also, If there is a documentation for easy migration, it will be helpful.
Routers in angular
As mentioned earlier, the two mainstream routers for angular.js is ngRoute an ui-router. There is the new router which is part of angular 2.0 - Although it promises amazing features, I currently do not recommend adoption of it and angular 2.0 until it's stable and because of stories like this and issues like this.
Read before upgrading
"Upgrading" to the newest stable release of any library is most alwasy preferable. But before you do; you should read the release notes for every single version up to the version that you're upgrading.
Check the migration guide
Google is working on improving their angular documentation. The migration documentation however is particularly good. Take a look at it here
Depending on the status of your project you might want to stick with the ui-router as angular 1.5 is backwards compatible with all your modules and the upgrade should be smooth (read the docs though, including the upgrade to 1.4).
On the other hand, Angular 1.5 is meant to bring us close to the concepts and architecture of Angular 2 and web components (which are now thought of as the future of web development) so it's a step on the learning curve that most ng1.x developers should take.
Angular 1.5 allows you to write your app in a component based fashion with a different routing mechanism, having routes/URLs load components that you defined instead of loading partials.
Routes can now be embedded in child components (say you have a Users module which has a /list, /details/:id/:slug, /edit/:id routes/sub-components and this Users module can be attached to whatever URL from your app: /users, /admin/users/ while keeping its internal routing mechanism. Your base app will have non-terminal routes for this kind of components (specified with /... meaning it will leave the consequent routing to the component itself).
Also, you can have multiple active routes at once (i.e. think modals, as in Gmail where you can look at a message and have the Compose popup and then navigate to the message list while still having the Compose popup open).
Routing events are now hooks that you can implement in your own component so you can do your resolves locally (fetch data, check for user rights, etc), taking care of destroying stuff, specify whether the component should be reused or reinstantiated, etc.
Bottom Line
In Angular 1.5 the new routing mechanism is based on components instead of states/views so your app needs a refactor towards this concept in order to fully benefit from it.