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.
Related
We have several web applications(angular 7+) that we wish to present under one single page application. We are looking for a micro-frontend architecture/framework to use. As we see it, these are our options for implementation:
Using the single-spa open-source framework: https://github.com/CanopyTax/single-spa
Using Iframes (friendly Iframes) the hosting application (the shell) and loading each application according to the current URL.
Using web components.
Other?
The current state is a monolith FE application that consumes the other child-application as internal applications via IFRAME (This approach is not scalable for us, because the hosting application is building all the products together, and nothing is really separated.)
Our requirements are the usual requirements for micro-frontend:
Independent development - Each team can work on their own repo and build their products regardless of the other products.
Independent deployment - Each application can be upgraded in production without the downtime and without interfering with the other applications.
Shared components - We're using Angular7 in our applications, and we have a proprietary 3rd party library (shared components and logic) that we've already written that should be shared among all of the products for similar look and feel.
We would like to have the ability to upgrade each application's framework (Angular, RXjs, Typescript, etc and also for our proprietary component library) without caring about the other applications.
We tried to use the single-spa framework but we have some issues and we are currently found our-self thinking if this is the right approach for us, or should we try a different approach.
The issues we have using the single-spa are:
Assets loading is problematic. (We must have the assets files on the root folder of the hosting application, and we suffer from assets conflicts when switching to another application).
We still don't know how to handle global styling for all applications (We use sass for styling and it must have complied together with the local styles for each application)
Upgrade angular framework (or all other frameworks) is not possible for one application, it's all or nothing (since we have one instance of angular).
We have to implement a different bundling for development another side of the hosting application (the shell).
When we think about the Iframe (using friendly Iframe) solution, we visualize a full separation between all child-application. Communication is via a post message alone. In this approach can we separate UI Code out of this and make APIS alone to work via IFRAME
Are there any pitfalls for using Iframes?
A more general implementation was to create a web component with a custom element, but we need to support IE11 and Edge which do not support native encapsulation, so we would need to test our app in every site where it is used, to make sure they are not breaking our styles, also I don't know whether a web component can manage child routes or not.
The ideal solution should allow our PARENT application to request the child applications via routes without any coupling between them in terms of resources and assets and should be independent in these terms. Another major feature we need is these applications should have a notification mechanism across them.
Thanks in Advance.
I am developing an involved web app with asp.net core.
I am developing React components, writing all of my components with ES and JSX syntax.
I run webpack to transpile all of my code (so now I have pre-transpiled files ready to be served)
When a request comes in, I just serve my pre-transpiled bundles.
I wanted to have a way of only bundling and sending user-specific components (based on a list of features they have access to) to the client.
The only way I could figure doing this is to do "on-the-fly permission-controlled component bundling combined with on-the-fly jsx compilation" to serve my components.
I gather that webpack shouldn't be used as an on-the-fly bundler like this, so that is out of the picture...
Partial scrappy solution I came up with:
Using no importing or export mechanism in my js, I use Razor to cycle through my feature list, adding the appropriate (mostly modular) components in what I call "Dependency First Order" to the page, and at the end of each components' code, I write
class ComponentA extends React.Component { //Component Code Here }
window.ComponentA = ComponentA;
So all components are global and can be rendered.
This way, I am able to select what Components get sent to the client with Razor.
NOW, remember when I said "mostly modular"? Well if I am rendering a component within another component that the user doesn't have access to, this partial solution would leave the render statement embedded in main component that is rendering the sub-component itself, without the component code it's supposed to render actually being there. This being a dirty partial solution, I would just suppress the error if the component was non-existent and move on.
Bottom line is I am having a real difficult time making my react components 100% modular and being able to control the granularity of my 'component dependencies' so that no code is on the client that a user shouldn't have access to.
Ridiculous solution someone offered me:
It is also certainly out of the question that I would generate a set of bundles for every user and whenever an admin changes what a user has access to, I would re-render that bundle with webpack. (especially since I am dealing with thousands of users here).
As I am writing all of this, the more and more I feel like I am just being a perfectionist and should just go with the above paragraph.
The solution I should probably go with:
There is the ideology out there to just send all of your js to the browser and then selectively render them based on the permission of the user. Any security loopholes here would just be handled by server-side access control to lock down endpoints if a specific user did try to forge requests to parts of the application they don't have access to (which would be implemented regardless).
I am under the gun here and feel like I am overthinking most of this. I would be greatly appreciative of any feedback. Thank you.
It is possible to ship permission based JS bundle to client. You can leverage webpack dynamic import logic to load only required features JS bundles.
You need to create directory structure based on features and load them based on user permissions. Basically what webpack does is, it creates separate bundle for each feature and load it via dynamic import when requested.
Solution here 👇
Note: You might not see lazy bundles in codesandbox.io network panel, but, you can download project and run server locally to see bundles being lazy loaded.
I'm completely new to Angular. I currently have a Django app that acts as a JSON-serving API (using Tastypie) and also serves up a few static pages for things like user registration, invitations, and viewing events.
Eventually, we're going to have a webapp that interacts with the Django API in all kinds of ways and makes total sense as a single page web app written in Angular (or something similar). However, as it stands right now, I just want to separate out these relatively self contained pages (mostly forms, confirmation pages, and event viewing pages) into their own app.
Since eventually everything is going to be in Angular, my thought is that I might as well start making these things in Angular, even though Angular's architecture doesn't seem very tailored to small forms and other things that will likely just be linked to from email messages.
Does it make sense to build these things out using Angular, setting up the necessary service/factory calls, making controllers for the form/event viewing pages, etc.? And if so, what's the best architectural decision in terms of modularity? Should every part of the app that "stands alone" (i.e., doesn't really interact with other parts of the app) be a separate Angular module?
If they are literally separately loaded pages and you eventually plan to have these pages be part of a single page angular application, Than what I would do is:
Create angular modules that have the same variable name for all seperate pages so like var app = angular.module('blah',[])
I'd link all my controllers for each individual pages at the time to their specific "app" module app.controller('blahCtrl',function(){}); ...
You boot these modules separately on their respective pages for the
time being
then when you do make the transition to moving it to one module where everything is in one page you can simply port the controllers because they will all belong to a module represented through the variable "app"
I'm pretty new to Sencha Touch and am trying to make a simple application that has a login form and makes calls and fetch results into lists.
My question is, how should I create the structure of the application? Should it all be inside one .html file? or should I different pages for each list and the login page? If so, how can I change views from one page to another and get transition effects?
There is actually a generator which you can use to generate the canonical app structure. From the Sencha download, go to the jsbuilder directory, then run a command similar to this:
./sencha.sh generate app MyApp path/to/myapp
Also, this slide set demonstrates the structure, though you may have to dig for more of the philosophy for why things are where:
http://www.sencha.com/conference/sessions/session.php?sid=322
And here's the example app talked about in the discussion:
http://cl.ly/1d1S282O1Y2c3N1v1j1i
It's fine to use a single HTML file to get things started, but in the long run it's worth making the application structure consistent with 'best practices' so that others can look at, and understand, your code subsequently.
Sencha Touch generators (coming in v1.1) place the launch logic in a file called app.js and then have files for each model, view and controller (in respective directories).
While you may not be building a fully fledged MVC application from the start, you should probably still use these conventions. Take a look at the Twitter and Kiva apps in the SDK (and at http://dev.sencha.com/deploy/touch/examples/ ) foor good examples.
The index.html file can link to each file individually, but of course for production, you are also advised to look at the JSBuilder tool to package and minify them all so that the device can fetch them in one single HTTP request.
I would break it up by major function (i.e. purpose). For mobile apps, you want to avoid having unnecessary postbacks / loading multiple pages and views if you can help it.
If your mobile app has one purpose, I would keep it on one html page and only break up the JavaScript files as you need to keep it organized.
If it has two purposes (e.g. 1-to ENTER a bunch of information, and 2-to display reports on your data), then I would break it up into two html files.
For example, if you have a mobile app that takes you through a series of wizard steps to perform data entry (i.e. single purpose), I would house that whole wizard inside of an Ext.Panel (on a single page), and swap out each content Ext.Panel "step" of the wizard as the user progresses through the wizard.
Start with the simplest thing and refactor later. I've just done an app in Sencha Touch and it gets quite bewildering looking at the example files. I found the easiest way to learn was to create a single html file and as soon as something became unwieldy or obviously needed a refactor I started creating subsequent files.
I've just started developing an ExtJS application that I plan to support with a very lightweight JSON PHP service. Other than that, it will be standalone. My question is, what is the best way to organize the files and classes that will inevitably come into existence? Anyone have any experience with large ExtJS projects (several thousand lines).
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ
I would start here http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/
This site gives a good introductory overview of how to structure your application.
We are currently using these ideas in two of our ASP.NET MVC / ExtJS applications.
While developing your application your file and folder structure shouldn't really matter as you're probably going to want to minimize the release code and stick it in a single JS file when you're done. An automated handler or build script is probably going to be the best bet for this (see http://extjs.com/forum/showthread.php?t=44158).
That said, I've read somewhere on the ExtJS forums that a single file per class is advisable, and I can attest to that from my own experience.
I suggest users are willing to wait for an application to load, so we typically load all of JS during initial app startup. I suggest loading and eval'ing JS files as needed is unnecessary - especially when all JS will be minified before deployment to production.
I suggest namepsaces, one class per file, and a well-defined and well-documented class hierarchy.
When starting new big project, I decided to make it modular. Usually, in big projects not all modules are used by a particular user, so I load them on demand. F.e., if a project would have 50+ modules, the big probability is that user is working only with 10-.
Such architecture lets you to have the initial code relatively small.
Modules are stored on the server and loaded by AJAX call, eval'uating the responseText in AJAX callback. The only issue with this, you must keep track on module dependencies, which could be stored inside modules as well. I have a class called Module, and I check every new module instance for existance within the task. If it doesn't yet exist, I load it from the server.