I'm currently adding ember.js to an existing rails app. Is it common to serve different ember apps based on route if the functionality is substantially different? Or is it better to keep it as one ember app?
The way that Ember intends you to use it is that you have one Ember application, and all the back-end stuff such as database interactions are handled by Ruby. Ember just communicates with the back-end to get what it needs.
However, if you feel comfortable having separate Ember applications on different pages, then that's absolutely fine, but it's not how Ember would like you to use it, since it's an ambitious framework.
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.
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.
I have been working on a web app using .NET web forms. Now I'm trying to move to a Web API and a client side application. I'm trying to use Ember.js right now. I'm starting to get confused with Ember 2.0, Ember-Data and stuff.
My problem right now is that I'm trying to consume some of the REST services in order to show a list of things in my Ember app. Is it mandatory for me to use Ember-Data? If not, how can I consume the services to create, read, update and delete items (I mean, am I able to use only ajax or something)?
The Web API was built in order to be usable for many technologies. I need to build an specific URL for each request (even a simple GET has some mandatory parameters). That's why ember-data is not working well for me, at least not what I have learnt about it. Because this.store.find won't allow me to build the URL I need.
Greetings.
Is it mandatory for me to use Ember-Data?
No, it's not. You can use other libraries such as Ember RESTless, or write your own.
You can even use simple jQuery AJAX calls whenever you need to fire a request to your API, however, you'll loose many benefits of Ember Data, such as lazy, asynchronous loading of models when they are needed.
That's why ember-data is not working well for me, at least not what I
have learnt about it. Because this.store.find won't allow me to build
the URL I need.
You can override buildURL method of adapter you're using(for example RESTAdapter), source code on GitHub could be helpful if you would like to do that, and you can find everything you need to create your own behavior for buildURL method in Ember API documentation.
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.