Our company is slowly transitioning a long-standing product from Backbone to React 15. We are limited to React 15 because the product interacts with other shared products, and the life cycle and build processes we use don't support JSX (as well as other things).
So right now the core application is Backbone, routing, view, models, etc, all handled by the Backbone framework. What we have done is injected React into some of the views, so that while the basic functionality such as the header and footer bars are controlled by Backbone, the internal view, the main user interaction of that particular view is a React application embedded in the view.
All the React code is in one folder, with many, sub-folders, well organized. We want to have documentation for this code only, using something like docz or react-docgen, but those don't seem to work as the git repository and npm roots live at the root of the Backbone app and not the React code folder.
Further complicating the issue is that the React code is in a sub git-repo inside a git-repo (this product has been around a long time).
Any thoughts on how to generate a doc site given these parameters?
Thanks
Related
probably I have a conceptual error regarding Module Federation. What I am trying to do is create a "shared project" (reactcore) that loads react, react-dom, MUI, etc, but not any specific UI. and the other UI's (diverse widgets) that I want to load will reuse the react and other dependencies offered by the core (use the core just as a library provider).
what I got is that if load both scripts (mpreactcore and mpwidgets, the one with the UI) it works, but react and react-core are being loaded TWICE.
[![screenshot][1]][1]
[1]: https://i.stack.imgur.com/rXEYB.png
I am wondering if I am trying to use Module Federation the wrong way. perhaps it is mandatory that the "core" should be a "shell" and all the other widgets should be injected in the shell, for example, passing a parameter when creating a single App component? my approach is due to the fact that my widgets are loosely coupled, more like a library of utilitarian widgets rather than a massive unified UI.
thanks for your recommendations.
I am wondering how to add React into an existing ASP.NET Core MVC project in Visual Studio 2022 (no, I cannot use VS Code). I can see templates in VS2022 to create new React projects, but I have been unable to find any tutorials, videos, blogs or vlogs to show how to add React into an existing project, so I am wondering if it can be done.
I have added react.js and react-dom.js to the project and I am able to create pure javascript components using those (no JSX), but I would like to utilize more of what React has to offer.
=========================================
After the request to ask a more specific question, including the project in question . . .
I am currently on a small team working on an ASP.NET Core 6.0 MVC application. It is currently using jQuery and jQuery-UI components within the CSHTML views for the UI. There are some $.ajax calls to an API for data, but most data is loaded with the model of the view.
My boss has asked me to look into utilizing React and the reusable components on the next module that we will be working on, without replacing the entire app into a "new React application".
Every single example, video, tutorial that I have watched uses VS Code or some other IDE (other than Visual Studio) to run commands on the CLI to "Create New React App", but nothing on how to "Add React to an Existing App".
Before I go back to him and tell him that I do not think we will be able to do what he is asking, I thought I would see if anyone here could point me to anything that could show that it could be done.
Specific question: can React be added to an existing ASP.NET Core 6 MVC app in Visual Studio Professional 2022 in a way that will allow linting, testing and JSX for reusable React components?
I think I know what you are trying to achieve:
Replace what you used to do in jQuery with React and to do so without
having to move to the whole VSCode, Create-React-App (or Vite), "npm
run stuff" environment.
You can indeed do so: I have setup a .Net6 project which is the standard MVC stuff that you are already used to, stripped out jQuery that comes with it, added Bootstrap 5 (no jQuery) and then used this (https://beta.reactjs.org/learn/add-react-to-a-website) to actually add React just as a library - JSX included.
The final bit that is missing is the JSX babel warning I get. I just need to add something to my MSBuild that will minimise all my JavaScript and JSX components and I'm done.
Everything in Visual Studio too.
You can easily build components and I use a watcher on session storage to tell the state to render and it works pretty well.
The main reason I did it was so I didn't have to use NextJS because I don't see the point in learning/using NextJS and it's whole environment because its "Server Side Rendered" when that is what we have been doing for years in .Net MVC, Wordpress, and every framework/CMS you can think of.
Note, I am not against Next I am just at a point where I only use/learn tech if there is a benefit. I can clearly see the benefit of using React over jQuery.
My public facing app needs to be actual HTML coming from the server not a client side rendered page.
My private login area I build using Create-React-App (or maybe I'll switch to Vite - as I am rebuilding it) and I do all that in VSCode.
we're working with Apostrophe CMS v3 and we're trying to add some custom apps to the pages with React. I was able to add components inside using the React CND scripts and loading components as script files in views/layout.html. But it probably isn't best practice. I was wondering if theres a way to add React apps into Apostrophe using npm packages and imports. Thank you very much!
It looks like this question was cross-posted to the Github Discussions forum: https://github.com/apostrophecms/apostrophe/discussions/3393
The response there from the lead software architect:
You can do it in two ways. Which is best depends on your needs.
If you are building a single-page React app but you need some dynamically edited CMS content, you should most likely keep building your React app just as you have been, and use Apostrophe's REST APIs to access piece and
page CMS content where you need it. See the documentation on our REST APIs.
On the other hand, if you are building a pretty normal CMS-driven website
but you have a few experiences inside your pages that would benefit from
embedding a React application, you should carry on with your Nunjucks
templates for Apostrophe as you normally would to build a website with
Apostrophe, and in addition set up a webpack build of your own to build
your React apps, and push the output to a ui/public/build.js file nested
in any module of your Apostrophe project. Any .js file found in a
ui/public subdirectory of a module is automatically included in the
frontend bundle generated by Apostrophe.
In that situation, you can still use the REST APIs to access data from the
React app, or you can pass data via data attributes in your markup. If you
do the latter, the | jsonAttribute Nunjucks filter is helpful to turn it
into a string that is safe for incorporation into a quoted attribute in
your markup.
Hope that helps!
So the question is if it is possible to split a React app into two different separate apps hosted on two different hosts, where the app A is a kind of a frame which controls the app B and C in the future. I have a problem, where I would like to make a common fundament for both apps (the A app) and then load two other as a content of it. It would be as if I had lazy loading with a bundle fetched from a different place. I was thinking about three main possibilities:
Iframe
Single SPA project from github
using ReactDOM.render method
I am not sure if it is possible at all, beacuse there still may be a problem with React Router - does the inside app have access to manipulate the browser routing?
It is quite possible to split your react Application into multiple smaller react applications.
Suppose you have a react application such as an e-commerce platform . You can choose to write the cart Page using a separate react-App and the products page using another separate react app and integrate them together using Module Federation Plugin webpack/lib/container/ModuleFederationPlugin.
A good reason to do something like that would be to develop different parts of your application in isolation ..and they can be taken care by different teams altogether.
There is a udemy course that teaches you exactly that. Very much recommended. You can make react dependency as singleton to avoid several installs of react.
All 3 of these options you've stated are valid and can be used to share components but there are few disadvantages to each one, for example- iFrames makes it hard to create responsiveness, ReactDOM splits your app so that the different parts won't have the same global scope...
Module-Federation is the best and most efficient way to share remote components that i know of, here is a github link to a basic project.
The MF plugin makes use of webpack's abilities, which means that the shared components are being consumed as runtime objects of the app's scope, rather then as a promise of an iframe.
NOTE: Debugging and updating a Module Federation project is a much deeper task then debugging a create-react-app application, you'll need to share dependencies correctly and remember to update desired changes at all the right places all the time.
This is not possible. Each react app can only have a single package.json in the hierarchy. if you nest it, the app will fail and say you have several installs of react. what you should do is think more react minded and objecty. You can have a folder for common components to share inside src/. You can also have src/A which is one "app". src/B which is another.
What you described in your question is exactly what you should do, just dont think of it as a react app separation, rather a seperation of component and app inside the src folder. App A can be comprised of components from /components as well as App B.
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.