I'm developing an application with this structure
App
Pages
Profile
Account
etc...
Modules
nameOfModule
nameOfModule
etc
In the Pages directory I've got all the different pages in the application, switching between these pages will cause reloads.
In each of these pages directories, for example Profile, I've got 3 files(may differ)
router.js
main.js
app.js
main.js is called using requireJS and the only thing it does in set some paths for the dependencies and then it just calls the initialize() located in app.js wich in turn simply initializes the router in router.js.
My problem is, how and where do I connect the modules to the actual page?
Lets say I've got a few modules that are supposed to show up on the Profile page, lets call them Module1, Module2 and Module3, where do I organize these modules for the page?
It feels wrong to organize these kind of things in the router? Where do I decide wich modules I use and where they go?
You may consider using Marionette's Module to help you
https://github.com/marionettejs/backbone.marionette/blob/master/docs/marionette.application.module.md#starting-and-stopping-modules
Related
I am using django on the backend and on the front end I am using react with create-react-app.
I have different apps on my web page that are somewhat independent from each other:
mydomainname/home
mydomainname/foo
mydomainname/bar
They are all somewhat connected but logically completely different which is why I separated them.
Is this handled with only one create-react-app and one index.html file in the build folder? And something like the browser router package for the different apps?
For example, if I look at the Facebook homepage (in case I want to build that with React) I understand that my news feed and my profile page and other people's pages are all connected and share similar components which is why it would make sense to have one index.html file.
But if I create a new public page (e.g. for a business figure), are all these components and functionalities handled in the same one index.html file? I could imagine that this will run into memory leaks and performance issues, or is this not the case? I can't seem to find anything about that neither in the create-react-app documentation nor through google.
React is not Html. In React you have only one page named index.html in folder public. The "pages" in react are named as 'Components', so you just create components and link them to each other. The first generated example component is App (App.js) component in src folder. All the transitions (transition from one component to second) will be done in index.html file.
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've been messing around with Angular and i wanted to split all the files up according to their role in my app.
I want a folder for each "page" like /home or /products and take care of everything within their respective folder(It sounded like a great idea).
However, now i'm not sure how to approach loading these files in or even where to do it.
This is my current file structure:
Due to certain limitations im not able to use other helpful tools, this needs to happen in the code directly.
What would be the best way to approach this?
1st part of your question:
There's no default way to organise your angular app.
However, there are some guidelines. I keep thanking myself for reading the Angular 1 app-structuring-guidelines by John Pappa which enlightened me on the same question you are asking.
At the moment, I have organised all my apps in a folder-by-functionality apprach rather than a folder-by-type one (i.e. all controllers in a controllers folder, all services in a services folder,etc).
2nd part of your question:
Just use Gulp or Grunt and then import the single file in your index
The Web is getting more and more component oriented, now all the most famous frontend frameworks adopt a reusable component policy (React and Angular 2 relies heavily on it)
If you want your angular app to be as modular as possible, you have to put everything regarding a component in a separate folder (html templates,css styles and js logic),and split the shared logic between services and assets
In Your case an example of project structure could be:
app/
assets/
//put here images,fonts and shared styles
services/
apiService.js
utilsService.js
etc etc ...
components
home/
home.js
home.css
home.html
products/
products.js
products.css
products.html
etc etc/...
index.js
index.html
I'm working on converting an existing patchwork app into an Angular app. The app is built on a CMS that bundles "components" together as packages that are reusable throughout the site, so the most effective solution right now is to bundle the relevant JS to a unique component as an inline <script> tag and leaving global functionality in a separate JS file that every page on the site shares. The CMS doesn't work well with SPA's yet.
One roadblock I have found is that I am declaring an ng-app="siteApp" on a shared template to all pages (hence every page has this app).
On a given .html page for a component, I have a controller ng-controller="RecipesCtrl" and want to tie it into my app. I can't reference siteApp on this internal page, even though it exists in a global context: https://docs.angularjs.org/error/$injector/nomod?p0=siteApp
If I include all the filters/controllers in the same .js file as siteApp, it works. If I put the controller on a different file that loads after siteApp, it can't find siteApp. Is there something obvious that I'm missing?
Thanks.
Without knowing the CMS it's hard to put a finger on anything but try chunking things into modules and injecting them as dependencies in siteApp.
Global JS file
angular.module('siteApp', [
'siteApp.recipes',
'siteApp.ingredients',
'siteApp.etc...'
]);
Component's JS file
angular.module('siteApp.recipes')
.controller('RecipesCtrl', [function () {
}]);
we are currently working on a big project in Marionette. We've based the architecture on http://www.backbonerails.com/. The project is divided in number of modules , every with its own responsibilities. It's important for the modules to be reusable, so they can be rendered in any region on the website. Right now the modules are initiated like this:
App.execute "module:name_of_the_module:action", #model, #layout.regionName
This worked good so far, but now we added Routers to the project. Every module should have responsibility for their routing, so they are in the modules. Now when the routers get the route and start routing, they are missing the region and model to work with. So we first have to save the region and models to the module to be used in the router later.
App.commands.setHandler "module:name_of_the_module:action", (model, region) ->
MyModule.region = region
MyModule.model = model
This is not really a good way to do it, because there is usually many actions on every widget (show, edit, create, ...) and we would have to duplicate a lot.
So I am asking - how do you initialize your modules and work with the routers? Is there some best practice?
I've create a marionette.js plugin which allows you do state based routing(much like angular.js ui-router). You can completely eliminate modules in code and reuse controllers.
Link: http://ajency.github.io/marionette.state/