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.
Related
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.
Having tested a simple (hello world) app in ember a few months ago, I was really excited because I knew that Google was able to fetch and therefore index it. Another app I built in Angular a few years was also being indexed! So I pressed on with my ember development and now have an application ready to deploy. This uses a PHP/MySQL backend api.
Today, I uploaded the production build to a server and then checked things in webmaster tools using the fetch and render tool. This time, nothing is being rendered !!!! I have double checked and uploaded the hello world app to the same server, which was fetched and rendered without any problem. I have absolutely no idea why this is happening!
I then looked at ember-cli-fastboot (having not really worried about it before because I thought that Google could index single page apps) and when I run
ember fastboot --serve-assets
I get
jQuery is not defined
ReferenceError: jQuery is not defined
So I'm now at a complete standstill after a lot of work!
Any help in resolving this would be much appreciated! Ideally I don't want to have to use fastboot, but if I have to, I'm not sure how to resolve the above issue.
unfortunately, ember-fastboot has some limitations and jQuery is one of them. You could use Phantom-based prerender instead.
I have a single page app built with emberjs with an a rails backend. Is it a common pattern to build an admin interface on rails serverside on a subdomain. What is the right approach for this?
Your question is vague but I will try to answer it my best. I have done this with a Node and a Go backend combined with Ember.js.
No, there is technically nothing to prevent you from doing a single page application for an admin interface.
Rails is a good choice for this, and generally you should stick with the backend framework/language you and your team master the most.
As for what would be the right approach, there is no magic recipes. Document your code, write test and follow best practices for the tools you are using.
One key element though will be the communication between your frontend and your backend. Ember chose to follow the JSON API specification (http://jsonapi.org/) and comes out of the box with an adapter to talk with these kind of API. Using such adapter will help you save a lot of time.
Here are some implementation of JSON API for Ruby : http://jsonapi.org/implementations/#server-libraries-ruby
One more thing about your frontend code structure. You haven't say how big your app will be. If it gets big, you may want to take the pod approach in ember-cli (http://ember-cli.com/user-guide/#pod-structure). It basically changes the structure of the code so it's easier to maintain a lot of files.
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 :)
I'm evaluating ember.js with ember-data and meteor for a single-page web app.
So far my conclusion is that meteor can best be compared with a combination of ember.s and ember data while ember data takes the role of minimongo.
I really like the real-time sync of data with minimongo in meteor and would like to see this feature in ember.js. My question is whether we will see this or whether this is totally out of scope? Maybe there is a secondary lib or project which could be plugged in to have such functionality?
The question is pretty specific but I think for this topic any broader scoped contribution can be valuable.
Thanks
An ember-data store can be fed by many sources via adapters, one of which could certainly connect with web sockets. I prefer ember's clean separation of store from adapter to meteor's approach, which seems to require tighter coupling between client / server (I may be wrong here - I admittedly don't have experience with meteor).
You might want to check out Paul Chavard's (#tchak) colors-demo, a rails / ember / web sockets app that replicates the original Meteor demo. It's a quick proof-of-concept app and may be a bit outdated at this point, but it certainly shows that real-time ember apps are possible.