I have a 'core' Ember application that needs to be able to be extended by 'child' Ember apps. In Ember 0.10, this was achieved by heavily modding grunt tasks, but Ember 2 appears to have a possible workflow for this built in.
A super high level summary of my current (and target) setup:
core-application ('core')
contains shared business logic across All apps + templates and components
plugins
shared templates and logic that can be reused across apps (but not needed by all)
application
is composed of elements from core-application, plugins, + any app specific code. a note that routes should be able to be 'pulled in' from 'core'
In the current Ember 0.10 app structure, this has worked by modifying grunt tasks to build the apps in a quick, fairly fool-proof way.
Now, in Ember 2, it appears that this sort of pathway for app development is provided by using addons and blueprints. I suspect my 'core' app should become a 'blueprint' and plugins could be either an 'addon' OR 'blueprint' based on what is required by them. I'm writing proof of concept code now, but I have the following questions:
what does the --blueprint flag for the ember addon command do? I see that it essentially generates an app structure, but I don't see any realy documentation regarding where to go from there. This appears to to be what I want to use for my 'core' app, but the documentation is lacking here.
If the above --blueprint flag isn't what I want for this kind of set up, is there a better approach I should be considering?
Any other info regarding the above that folk with greater Ember 2 + ember-cli experience than I have can share on this would be hugely helpful.
Thanks in advance for any all feedback.
I found my answer by digging around existing Ember community addons.
The ember admin project seems to outline the structure AND consumption of an Ember addon that essentially creates an Ember app complete with routes and overridable/extendable elements.
The Host application then 'mounts' the admin addon by importing the admin addon's routes to the host application's routes and BOOM things work as expected. I've been able to write POC code to prove this concept works for my needs.
Related
We need to create a PWA with angular which will wrap the ember application and communicate through some navigation and events.
PWa will be just as a container which hosts the ember so that the application can be used as native and as webapps through every devices.
We need some approaches to get some solution regarding the above requirement.
Will it be possible for everyone to give some light one that.
Planning to host the application using iframe under PWA and communicate.Not sure whether it will be helpful or not.
It's not the best idea to use Angular to create a PWA for an Ember app, you should be doing this in Ember.
One reason that it might not be the greatest idea is that if you're adding Angular to your setup you are adding a minimum of 130KB of compressed JS before taking into account any features that you might be using. Assuming a baseline Ember app size you're talking about adding a roughly 60% extra JS to achieve something that can also be achieved by Ember.
It sounds like you might be following a tutorial on how to turn an app into a PWA that is based on Angular. If you are you having specific issues that you don't know how to solve with Ember I would recommend joining the Ember Community Discord and asking for some help there and maybe someone will point you in the right direction.
Is it possible have multiple apps that share UI/CSS/libs etc. in one yeoman ember project with one Gruntfile.js?
I have tried using the Yeoman ember generator, and it is wonderful for 1 app environment at a time.
But my situation is that I have multiple ember apps (that are required to be separate because of work oriented restrictions) that all use the same UI (LESS/CSS, bower_components).
So, instead of having to initiate 5 different build environments (Yeoman ember generators) that duplicate the same UI elements, I would love to be able to have them all in one build environment instead. I have tried building the taxonomy and tweaking the grunt tasks but it seems that the Ember compiling logic for the 'generator-ember' only looks at the index.html in the root.
Any info/insight is welcome.
I am working on an Ember-Rails app. I have used Yeoman previously for building non-ember-rails apps and js plugins and I would love to be able to realize the benefits of Yeoman (especially Grunt's livereload) when working on my Ember-Rails projects. However, I am unsure as to whether Ember, Rails, and Yeoman are fully compatible and whether they overlap in their roles and responsibilities. For example:
Dependency Management
- I understand Bower is used for dependency management. Does Bower affect how assets are loaded through the rails asset pipeline? What are the advantages/disadvantages of loading dependencies through Bower instead of using Rails gems?
Livereload
- Does livereload function with a single-page app (like one built in Ember) in the same way it does with a multi-page app (for example, an html site that doesn't use a js framework)? Are individual models/views/controllers reloaded or does the whole app reload and/or recompile through the Rails asset pipeline?
Existing Project
- Are there pitfalls when integrating Yeoman into an existing Ember-Rails app? We're running Ember 1.3.0-beta and Ember Data 1.0.0-beta on our production. If you have experience with up-to-date Ember builds, are Ember-auth and Ember-data compatible with Yeoman?
If anyone has experience combining Ember, Rails, and Yeoman, or if you understand how the frontend and backend would compare with such a stack please share your thoughts! Would you recommend just integrating part of the Yeoman setup (e.g. Grunt) with an Ember-Rails app instead of the whole of Yeoman?
Thanks.
I'm not Rails&Ember guy, but here are my general thoughts about feasibility of using Yeoman:
Not using Yeoman: Feasibility
From my experience in combining Yeoman & Django, I must say that it starts to pay off only in medium-sized or bigger projects.
In smaller ones, particularly with tight deadlines and not much attention paid to the code quality & tech. solutions used (like Univ. projects), you'll be probably better off sticking with bare Rails (downloading JS libraries manually and committing them accordingly to the Rails project structure).
The reason is simple: It might be really time-consuming to fine tune both full-stack framework (Rails) with frontend-framework (Yeoman).
Particularly if Rails is driven by CoC principle.
It might seem to work after some setup, but as the project evolves, you will spot further obstacles and you'll have to tamper waaaaaaay more.
Cons & things I consider not worth this time investment:
Livereload
I like it very much, I was amazed with it at first, but after some time I see that I don't spend that much time editing HTML&CSS in IDE and watching static page on another screen automatically refresh. In majority of cases I still need to do Alt + tab and trigger some action, perform some click, so whether I add one Ctrl+R hit in-between doesn't do any difference.
In some cases you'll be better off playing around with Local Folders Mappings (Chrome Dev Tools) or web proxy (e.g.: Fiddler).
There are cases where Livereload does a brilliant job though, such as for instance not needing to perform full reload if you edited only CSS.
As for your questions:
For me if it detects changes in JS it reloads whole page. But maybe it's because I'm using JetBrains IDEs (filesystem cache'ing) and CoffeScript (compilation to JS).
Yeoman is best suited for SPAs. Would it be acceptable for you to make it a SPA, not a round trip app ?
Bower - Attempt to provide dependency management for github projects
What bower does for your app is basically downloading stuff from github. No rocket science here.
If the structure of downloaded thing is non-standard, Bower/RequireJS/Grunt-bower-install has no bloody idea what to do with it next, i.e. how to inject everything so that you won't get errors. For most popular libraries bower just works, for highly customized ones you will end up injecting downloaded stuff manually.
The ones to blame are people who don't package useful github projects properly.
Furthermore I heard of workflows where people commit bower_components due to problems with bower, never experienced personally though, perhaps the issues were fixed. If so possibility of not committing 3rd libraries to source code is definitely an advantage.
Note: As I pointed out above, it's how bower helps you developing your app, but bower has become somewhat a standard in the frontend community, for instance http://ngmodules.org/ is build on top of that, so it's a important tool.
Can Rails assembly pipeline fetch arbitrary github project ? Yes.
Can it inject library references to your html ? Duno, I'm not Rails guy.
Generators
Some could do a beautiful job, such as configuring whole heroku-related stuff for you. Too bad generator-heroku doesn't work as expected (tried it sth like 2 months ago). Same was true for travis generator. In this case fix was easy, but see the next point.
As for Angular generators (I'm Angular guy, not Ember guy, sorry :-) ) - it just adds 2 files and includes them in index.html, furthermore if you are using not so straight-forward syntax for creating JS framework related stuff (sample: Angular-related stuff in coffee) generator will most probably not know about it. Ok, you can submit a patch to generator, but then AngularJS team decides to change the syntax a little bit in the next release - you get the idea ? - again, see the next point.
What is more, if your project uses layout in which code is structured by feature/module (e.g. admin module, profile settings module, ...), not by type (directives, controllers, ...) framework-specific generators won't work.
Stability
Karma is evolving rapidly, so does Angular, Angular-UI and loads of fronted tools, frameworks.
It's really difficult for Yeoman to keep up with most recent changes, although they do a nice job here.
Employing Yeoman: Being cutting-edge
Yeoman provides some really cool stuff such as:
Linting
Compiling coffeescript, SASS/SCSS, etc. on the fly
CDNifying
Really useful when you want to have libraries downloaded locally in case of developing offline and still benefit from pros of CDN.
Without Grunt you would have ended up writing scripts parsing your HTMLs
Automated JS/CSS minification
Grunt does it for you. You only have to configure it properly.
Encouraging separation and low coupling of your frontend and backend
As for your question: I doubt that you'll be able to manage Rails part solely with Yeoman.
A good recipe for a web app in Yeoman & sth is: https://stackoverflow.com/a/19425461/1432478.
That's for Django, adapt it accordingly to Rails.
My opinion
In majority of small projects based purely on Spring MVC, Rails, Django, etc. you simply don't perform any of things done by Grunt (hence there's less time expenditure for setup).
There are cases when producing technologically advanced frontend is a must.
e.g.: Most recently I discovered that my bank account management system doesn't minify JSes. Even funny comments are left as they were. I didn't perform any rushed money withdrawal, but I hope they at least have server-side validation. :-)
Yeoman is a really good combination of solutions facilitating all those chores.
Using only Grunt? IMHO No. Yeoman is Grunt when it comes to app assembly. You get Livereload and other stuff for free.
If:
you're lucky and found sample config that seems to work for the web framework of your choice or managed to configure one on your own
don't have deadlines to hold
then you should probably give it a try.
If you will work on multiple projects, chore of configuring it once might pay off by copy-pasting config to future projects.
But keep in mind that frontend technologies are rapidly evolving, that's why tons of samples from the net simply don't work out of the box.
Further reading :)
http://blog.tfnico.com/2013/07/considerations-for-javascript-in-modern.html
Java world here, but I hope some concepts will be useful:
http://addyosmani.com/blog/making-maven-grunt/
Javascript web app and Java server, build all in Maven or use Grunt for web app?
I have been studying Ember.js for about a week now and all examples I studied were single page apps. I have been told to work on a project which expands more than 30 pages and I have no idea what the directory structure would be and if Ember is the best tool as I have never seen an application that links to other pages in the project?
Yes, ember is a single page application, since you only go to one page, it loads the app then you don't need to fetch anymore pages from the server the ember app handles everything. For bigger apps like the one you're suggesting, you'd put each object type (models, controllers, routes, templates, views, etc...) into their own directory for organization.
I quite like to use Ember JS for SPA due to it's flexibility but when it comes to browser support, then I've no choice but to go for Knockout JS for implementing a SPA!
They are both great for SPA, Ember has lot more to offer, but for those that must still support IE7 then the best choice would be Knockout JS...
Hope it helps :)
In the project I am working on, we are using ember.js (1.0rc1) without ember-data which is working out quite fine so far. The reason why we decided to go without ember-data is that we already have some utility methods to handle the integration with the REST interface, and over all because ember-data is not part of the ember.js.
From emberjs.com:
Currently, Ember Data ships as a separate library from Ember.js, while
we expand the adapter API to support more features. The API described
in this section tends to be stable, however. Until Ember Data is
included as part of the standard distribution, you can get your copy
from the GitHub page.
So, to my questions and the input I am looking for:
how much do we lose/gain with this approach? (besides the REST integration)
experiences of somebody that actually might have started also without ember-data, and now migrated to ember-data
maturity of ember-data and its integration into ember.js
And there is another question, which might rather be for the ember.js/ember-data devs:
what's the roadmap to integrate ember-data into ember.js and how strong will be the impact on the APIs?
Thanks for sharing your experiences and giving some hints and advices. // ph
I use ember-data in my project and I'm very pleased with it. I saves you a lot of time developing your own stuff for communicating with the server.
At this time ember-data is not officially production-ready but I use it already.
Read this on the emberjs website about ember-data. It says:
Without any configuration, Ember Data can load and save records and relationships served via a RESTful JSON API, provided it follows certain conventions.
We also understand that there exist many web service APIs in the world, many of them crazy, inconsistent, and out of your control. Ember Data is designed to be configurable to work with whatever persistence layer you want, from the ordinary to the exotic.
There is more information on the github page. There is even kind of a roadmap in it...
Another advantage is that you can define your Models with their relationships. It's also possible to use transactions which are giving you the ability to rollback changes if something went wrong at the server.
I really like the vision behind ember-data that it's not dependent on the kind of backend you use. Or where you define your relationships. If you use Mongo-db where you define the relationships on the parent object, where others do that the childs.