I'm planning to create a bunch of (2 to 3) ReactJS frontends that all primarily interact with the same existing Ruby on Rails API. Each frontend will appear on a different domain, but will use the same graphic design system and UI. Because of this I imagine that they will be sharing a lot of code.
How would you recommend organizing the code for such a project? And also how would you deploy it?
Code sharing
In my research I found the solution of creating a node package that just contains the shared components/code. My concern there is that then the developer (me) would have to be constantly bouncing from the module's repo to the repo for each site.
I also noticed bit but wondering if I want to be so dependent on a proprietary service.
These frontend sites don't really need to be completely isolated from each other in different repositories—even though they are on different domains, you could almost think of them as different sections of the same site, in the sense that they are closely related.
Deployment
If, for example, all this code is kept in the same npm project, then it's conceivable that when deploying, several build scripts could build each frontend and then push each build to a CDN. Would that be a good strategy?
I'm new to Aurelia and I want to create an app that call for other apps.
Example : I want to create 3 projects, project A, project B and common and wish to call common in both projects A and B.
I've tried some examples with npm and others, but this never works.
Is there a simple way for doing that ?
Best way to utilize your common features for your 2 projects is to use an aurelia plugin.
Aurelia plugins are very good at encapsulting reusable components.
JSPM, the default package manager for Aurelia, supports private github repo and even local ones (easier during the early development phase).
So intalling your plugin in your project will be as easy as typing something like that :
jspm install github:mygithubaccount/myplugin#master
I would advise you to start reading one of plugin authoring blog post, then check the repo plugin to see how to package yours.
Check the blog post about AureliaFlux, it is worth reading.
You can also use the aurelia skeleton-plugin repository as a starting point.
Good luck.
As we're making our initial move into DNN and setting up projects, I need clarification on the Web Application Project model for creating DNN modules.
Should/can all modules live inside one web application project? Or, should each module be its own WAP?
What would best practices dictate for the project structure in the solution containing DNN modules?
You can do it either way. I've heard people do it both ways.
Do your modules depend on each other at all? If so, you might want to keep them all in the same project so if one gets built, they all do.
If not, I like to keep each module in a separate project just from a separation standpoint. Each module/project will be smaller and easier to manage. Just build the project and it will give you the install file.
It's just a personal preference. I know a lot of people create one solution, then keep a separate project for each module.
After having been convinced to learn and use Angular.js, I was going to start a concrete web UI application so as to launch the learning wheel of experience. ( The app is going to be some kind of personal planning, to do list, reminder, pomodoro technique oriented, and so on...)
One of the tutorial videos I have seen, by the author of Angular, is about best practices. And one of the best practices is to start with the angular-seed project.
That is what I was going to do, but after googling a little, there are already at least two other projects that claim to be the good starting point:
angular-enterprise-seed
angular-sprout
I'm beginner, but I like to invest in the long term. Should I worry about using something else than angular-seed ? I feel like it's too early to ask myself this question, but if there are already two other projects, maybe there are some good reasons.
I've found that though many people use various seed projects, the easiest & most consistent starting point for an angular app (or any javascript web app) is Yeoman.
This app is a scaffolding tool that allows you to specify generators which will build the up the kernel of your application, complete with whatever libraries you desire (via bower) and a working grunt build file (most generators come stock with a build task, server task for live editing, and testing task)
Though an app like this is necessarily opinionated, the scaffolding it produces is still very generic.
example:
mkdir my-app
cd my-app
npm install generator-angular
npm install generator-karma
yo angular
They all have different merits so it depends on what you are looking to do. I wrote angular-enterprise-seed and can speak to its relative merits.
It is server-agnostic. This is important since a core tenet of AngularJS, and one of many things that make it attractive, is that it follows the Client MVC paradigm. This means it is entirely decoupled from any and all server technologies. Many existing seeds tie AngularJS to server technologies, such as angular-sprout (NodeJS) or grilled-feta (Google App Engine/Java). In the case of the aforementioned projects, if NodeJS and/or Java environments aren't already on your system, then you will have to go through several hoops just to see the seed come up. This can be alienating to PHP and Python developers, which results in limiting the project's community.
Up and running in seconds. Because it is server-agnostic, it can be run in any container (heck the filesystem for that matter). Suggested method is running "python -m SimpleHTTPServer" from the root directory -- this comes native on Mac and Linux so there are no additional steps.
Live preview. It's cheap to check on status of the project because a live version is always hosted on github. Because it's server agnostic, this is automatically done by copying master to the gh-pages branch from a cron job.
Rich styling. It includes Twitter Bootstrap and custom/buildable LESS out of the box, along with Angular-UI, Angular-NG, fonts, and a myriad of other tools to provide rich styling and responsiveness capabilities.
Widgets. Like Angular-Seed and Angular-Sprout, Angular-Enterprise-Seed exemplifies "best practice" layout, routing, etc. But it also provides a host of pre-built components that can be taken off the shelf and immediately reused. This is a bit difficult to do as it can require the convergence of several technologies. For example, to create the grid example, I combined angular-ui, angular-ng, angular-js, and jquery styling. There are component examples for modals, pagination, alerts, grids, and more.
Angular-seed is great as an academic exercise if you want to learn how the pieces work, but it will leave you longing for a more substantial jump-off point.
I haven't used angular-sprout so I can't speak to its merits. Maybe there is some room to merge angular-sprout and angular-enterprise-seed?
I recognize that this is an older question, but it seems to have a fair number of views, so it makes sense to recommend what has recently become a very popular alternative to both Yeoman and angular-seed: ng-boilerplate. ng-boilerplate differs from angular-seed in that it's designed from the ground up for large production web apps, and therefore is a better solution than angular-seed in my opinion.
To explain the differences between the Yeoman and ng-boilerplate methods of app kickstarting, I'll quote ngbp's creator, Josh D. Miller:
Yeoman is awesome. But the problem I have with the generators for AngularJS is that they package by layer rather than by feature. If we store all controllers in a "controllers" folder and all services in a "services" folder, etc., and all our tests someplace else entirely, it can be quite challenging to reuse our components.
This is also pretty good discussion by Josh on the Yeoman angular-generator issues forum, that goes more in depth regarding the setup of ng-boilerplate vs. yeoman.
Just to be clear, Yeoman is not a generator. Yeoman is a format/system for making generators. There are several generators made with Yeoman that you can use to generate an AngularJS application. People often mistakenly refer to one or another of them as "the" Yeoman generator. But there are many. Confused yet? Yeoman isn't the only generator making system. Brunch is another one.
To answer your question, here is a very comprehensive side-by-side comparison of many AngularJS generators one can use to start making a web application with AngularJS. Currently, it contains over 200 different aspects of these things. One of them is file organization style. So you can easily see which ones organize the files by feature if that's important to you. It is to me.
There are still several of these left to be added. The two mentioned in this thread are new to me. But this comparison should give you a good idea of the options and how they compare. It's editable too, so if any of you are experts in any of these things, feel free to share what you know.
God only knows why people keep making more and more of these things instead of just helping to improve the existing ones. If you have any guesses, I would love to have that mystery solved.
EDIT: to gain access to the doc I ask that you either complete a questionnaire to share your knowledge of something or lobby the experts to do so.
Go here to do a questionnaire:
http://www.dancancro.com/technology-questionnaires/
I like using Yeoman as well. Try these to get a good scaffold:
npm install -g generator-angular # install generator
yo angular # scaffold out a AngularJS project
bower install angular-ui # install a dependency for your project from Bower
grunt test # test your app
grunt server # preview your app
grunt # build the application for deployment
I'm starting to build a rather big application in ExtJS Architect and I was wondering if it is advisable to split the application into multiple projects (to be precise projects as Architect defines a project)?
At the moment I am the only engineer working on this application, however more engineers may be assigned in the future. What would be the points to consider if you would to like to split up the project in smaller pieces or build one big project?
In addition: as far as I know it is not possible to 'share' a project in Architect over more than one developer. That votes in favor for splitting the project.
Disclaimer: I have not used Architect to build a project.
My thought on the matter is that if you are building an MVC project and you want Architect to manage your controllers and views you should keep all of it together. Especially if you have cross cutting communications between modules. However if you are 100% certain that your modules are completely standalone - meaning they have nothing to do with one another and might as well be separate apps ... (maybe they should?) ... then you could build them out separately and weave them back together after you are ready to ditch the architect. Remember its a one way street not an IDE. Bringing the modules together should just mean that the app.js now lists all of your controllers for all modules instead of just one for your module.