I am working on an existing native app where three different partner companies are working so three different react-native modules.
Here the problem is when they are creating a javascript bundle, it includes javascript core also in each bundle that is increasing the size of a native app.
Does anyone know what is the correct way to handle this problem?
Related
Is it possible to change/convert a plain react app into next app?
I have a project created with create react app but things have changed and now I want to switch the project into next app
maybe there's a possible way to do that? or should i start over from scratch to build my next app project?
I've been trying to research on how to migrate the project, but didn't found the solutions.
It's difficult to answer this question without seeing the actual project and dependencies you use, but here's a few considerations:
You'll need to convert your current routing solution to the one Next.js uses. Their routing is determined by the file system structure, rather than in code (like react-router). For more information, see their docs: https://nextjs.org/docs/routing/introduction
Ensure all your components and dependencies can render on the server, this may require moving behaviour that uses browser APIs into useEffect hooks (like window or document properties).
Move your hosting and building to something that supports Next.js configurations. There are a few including Vercel, Netlify & AWS.
Also check out their own migration guides that cover how to convert configurations to Next.js: https://nextjs.org/docs/migrating/incremental-adoption
In short, it really depends on what you're currently using and will require manual conversion your code. I hope this was still helpful.
So I have a React Native app developed using Expo and I have to somehow integrate it with other React Native app that doesn't use Expo. An additional requirement is that this other app (without Expo) needs to stay somewhat independent, that is, there has to be the possibility of developing independently and using it as a standalone app. One idea that I have is to create a third app and include those two in it as some kind of dependency. But I don't really know if it's possible and how to even start doing it. Searching the internet doesn't really help. Is such a kind of merge even a thing? Can I somehow treat a whole app as a component and include two such components in a third app? Or maybe I have to extract components from these two apps and build the third with them? It is actually my first encounter with React Native, so I would be grateful for any guidance.
it's just a simple question it has been more than 2h searching what to learn next ! i want something that will make me able to create a cross-platform app: web - android - ios . I've been teared up between NativeScript and react native + Reactxp.. i need your experience guys thank you !
bringing the power of web to phones.
As you want to share the same codebase for web and phone, NativeScript is an obvious choice.The Angular and NativeScript teams teamed up to create nativescript-schematics, a schematic collection that enables you to build both web and mobile apps from a single project.
A code-sharing project is one where we keep the code for the web and mobile apps in one place. Here’s a quick diagram to show you what that looks like at a high level.
The objective is to share as much code as possible, and split the platform-specific code into separate files.
This usually means that we can share the code for:
Routes for navigation,
Services for common business logic,
and Component Class definition for common behaviour of a component
While, splitting the code for:
UI Layer (CSS and HTML) - as you need to use different user interface components in web and NativeScript-built native apps,
and NgModules - so that you can import platform-specific modules, without creating conflicts (e.g. Angular Material Design - which is web only) between web and mobile.
To create two separate templates, you just need to use a naming convention. Simply create two files:
yourcomp.component.html - the web template file,
yourcomp.component.tns.html - the NativeScript template file - it is the .tns that makes it a {N} file.
You can even migrate from your existing project, you can fine the instructions here
P.S.The #nativescript/schematics package only works with #angular/cli: 6.1.0 or newer.
My application was in IBM WebSphere portal, where we have a centralized theme for all the portlets. We build individual portlets with the specific features which are then installed from a page into the portal like as shown below.
So altogether we build a portal with lots of portlets (individual web application). In the portal we creates pages and drag and drop each of these portlets as per the requirements.
Now the requirement was that we are moving everything to Micro service Architecture with Angular4 as the front-end. Currently I am having an angular4 application having many UI components and features. I am posting this question to get some ideas or possibility whether it is possible to create a portal like IBM WebSphere/ Liferay in Angular 4 with having the following basic features:
User/Team can create separate individual angular4 application, build and will be able to install/uninstall within the main application like porltets in portal (IBM WebSphere).
User will be able to view all the installed Angular4 application and can create pages, drag and drop those application within a newly created page.
Each separate Angular4 application (like portlets) installed will be using the main application theme.
Can anyone tell me whether this is doable. Do we have any framework setup in Angular4
One of the possible ways I can think of is using webpack(or any other module bundler) to handle the various angular application.
You can check out my answer here to get a brief overview of how you can configure webpack.
In the end, Angular compile to javascript only. So, It will be possible. But the effort needed to maintain and test the overall application might be huge.
When re-designing a system, it is best to think about the problem you are trying to solve and solve for that use case. It feels like you're trying to recreate the same bad interface with Angular. The code may be new, but the user interface problems will still be there.
I would recommend ditching the portlet idea and creating 1 app with many modules. Angular was designed to be very modular so different teams can work on separate modules. You could then have some sort of settings page where you can turn the modules on and off.
I have a requirement to develop multiple Angular 2 applications independently by various teams. Each team will have independent releases scheduled. Towards the end, all these applications will need to be injected into one main application at runtime. They will need to work as a Single Page Application.
We tried Lazy loading modules of Angular 2. One of the roadblocks we see is that we cannot compile the main application using web pack without having the lazy load modules in the project solution.
Here is the structure of my present solution:
Image1
This is how I defined the routes
image2
We have defined two routes that lazy loads two modules(LazyModule and MoreLazyModule). This solution works fine.
When we remove those modules from the solution try to build it using web pack, the compiler throws an error.
Is there any way we can decouple the modules to develop them as independent projects and inject those modules in production?
Lazy Loading is the solution for your problem (at least as far as I know).
If I understand correctly, what you are trying to build is an app which has an external container (app.module and app.component) which need to orchestrate several other independent apps. The whole thing needs to behave as a Single Page Application.
If this is the case, then what I suggest you to do is the following:
have a team (or an individual responsible for all the code of the
Container app (app.module, app.component, any other common code you
may want to share among the various apps) - the Container app
references all the subApps (and gets updates as soon as a new subApp
is added)
have different teams responsible for the different subApps - these
teams work on the code of their competence, submit to the code
repository when ready, but use the entire project (i.e. also the
subApps of the other teams) any time they build
I do not see any issue in organizing the work like this, as soon as every team checks in the code to the central code repository only when all tests have passed (and the tests cover the application functionalities thoroughly). The coordination effort required to the team responsible for the Container app is really minimal.