I'm using Ecwid with my Ember.js application, and I ran into a conflict. In short, Ecwid loads some JavaScript that embeds an e-commerce store into the page. The problem is that Ecwid and Ember both modify the URL fragment to keep track of state, since Ecwid is inherently its own single page application. Basically, I have two different JS libraries fighting over the URL.
So when I use an Ecwid component, the URL changes to an Ecwid URL, and Ember complains with Assertion failed: The route !/~/category/id=2104219&offset=0&sort=normal was not found because that is an Ecwid route, and not an Ember route.
I tried a catch-all Ember route, but that didn't really work because the Ember state changes away from the page I'm on.
Has anyone had to deal with a 2nd library that fights with Ember over the URL? If so, how did you maintain state and deal with the other application? As pushState and URL fragments become more and more popular, I could image this would become more and more relevant.
Really you're going to have to choose between the two, if they both are using the url for routing of some nature then they both rely on some notion of a base url, with a changing hash. In Ember you can disable the location routing, but then you lose the routing capabilities of ember.
To disable routing you'll just use the NoneLocation
NONELOCATION
Using NoneLocation causes Ember to not store the
applications URL state in the actual URL. This is generally used for
testing purposes, and is one of the changes made when calling
App.setupForTesting().
App.Router.reopen({
location: 'none'
});
I realize as I'm saying this, I'm partially lying, because you can use browser history instead of the hash. So your urls would just change like so:
/emberHome/fooResource
/emberHome/fooResource/fooBar
instead of
/emberHome/#/fooResource
/emberHome/#/fooResource/fooBar
Unfortunately there are some major drawbacks to this, firstly your server needs to know to serve your ember app at /emberHome and essentially ignore all nested locations. Secondly the browser support is fairly new (http://caniuse.com/history). Thirdly, the support for recognizing the Ecwid won't be supported, and will likely be blasted away when transitioning to different routes.
App.Router.reopen({
location: 'history'
});
You can read more about it at http://emberjs.com/api/classes/Ember.Location.html#toc_historylocation
Per the guides, you can tell Ember to not use the URL to interact with your application.
http://emberjs.com/guides/routing/specifying-the-location-api/
Straight from the docs there -
Finally, if you don't want the browser's URL to interact with your
application at all, you can disable the location API entirely. This is
useful for testing, or when you need to manage state with your Router,
but temporarily don't want it to muck with the URL (for example when
you embed your application in a larger page).
App.Router.reopen({
location: 'none'
});
Related
I am new to the Nuxt development platform, having worked mostly in Vue(v2).
Having delved into the docs and experimenting locally for a bit there are a few things I still require clarity on:
In static generation mode, does each page its get its own Vue app instance? That is, every pre-rendered page that is requested from the server behave as an SPA on the client.
If #1 is true, does every page, and in effect, every app run isolated from all other pages and apps? No shared state?
When using Vuex in SSG mode, does each page get its own Vuex store that is inflated with an initial state while rendering the page on the server? And, does this state get passed down to the client?
This store is destroyed on navigating to a different page (or even refreshing the current page), to be replaced by a new one right?
In SSG, every page is rendered ahead of time but at the end, will be hydrated and hence become an SPA. Nuxt is basically Vue on steroids but it's still Vue.
Not sure what you call isolated here, you can totally pass props, use emit etc... Meanwhile yeah, if you do have pages, they are not all loaded at the same time, there is code splitting + lazy loading + prefetching. Some info can be found here.
You can have namespaced modules out of the box when using Vuex with Nuxt. You do have nuxtServerInit to pre-populate the store yes. You could give a read to the Nuxt lifecycle btw. But you don't have a Vuex module by page out of the box, there is no real usage for this IMO. And yeah, you'll get your Vuex store on the client of course.
If you navigate to a different path with a <a></a> tag, you will nuke your SPA yeah. If you're using <nuxt-link></nuxt-link>, you'll stay in the SPA since the Vue router will make the "navigation". But yeah, if you type a path directly into the url and press Enter or refresh the page with F5, your entire SPA will be nuked and everything will be replaced from the ground up.
I've spoken at the latest Nuxt-nation, the quality is not amazing (sorry for this) but you could maybe get some interesting things out of it.
In my Ember app (actually mine is an engine within a host/parent app), I want to set the page title.
Now while I do
document.title = "Page title I want"
However, it gets overwritten by the host app i.e. what is set in the index.html
Where can I have the above code to set page title? Already tried adding in beforeModel, didTransition hooks, But that does not work.
I'd highly recommend standardizing across your app and all engines on ember-page-title. Which will allow you to add {{page-title "Blog"}} to a template. It has some additional features that are really nice when working in a larger app, but by delegating all of your title setting needs to a single addon you can have a standard API across your app and all engines for doing this task.
There are other addons that also serve this purpose, but this RFC has movement towards making ember-page-title the default for new ember apps.
I have created a dashboard in Keen and I want to use the same dashboard in my web application. Is there any way a complete dashboard can be embedded in another application?
Iframe won't work due to crossorigin restriction. Using javascript to create widgets of a dashboard is a solution but I wanted to skip the coding part of it. Reason for this is because if my client wants to update the dashboard then he can do so by simply updating it on keen and new build should not be required for such thing.
I work at Keen and you're correct that the iframe won’t work, because of the security changes introduced to the browsers to stop clickjacking attacks.
In the first iteration of “embed html” we used a static version of the properties used to store your json (which contains info about the charts to render and the names of saved queries to use).
We're working on deploying the updated version of the dashboard-viewer - which supports dynamic loading of the current state of the dashboard.
This should solve the issue you're referencing. If you would like to submit a ticket on our website would could provide a time as it get's closer to launch. Just reference this url.
https://responsivedesign.is/articles/xframe-options/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
I'm thinking about making something with the MEAN stack. I need a way to edit the content of the site, like e.g. Wordpress offers (basically a CMS).
The confusing bit is how the CMS and Angular would work together. I've looked at a CMS named Keystone, and there you have to set up some routing etc. in Node. Won't this crash with the routing you set up in Angluar?
In other CMSs I've used, the creation of the views happens on the server side. In Angular, as far as I understand, you crate a HTML template, which you can populate with data in an angular controller. This also seems like something that could crash between CMSs and Angular. Is this the case?
Is there any other quirks or similar about Angular and content managment systems I should know about, or is it usually not much problems integrating the two?
meanjs.org has a pretty good approach to this. Install meanjs. It comes with a sigin/signup and even allows you to create articles from the vanilla install.
Put simply, when you are creating a web app with the MEAN stack, think of AngularJS as "THE" app, and node.js as the api.
If you approach building your web app as a javascript application (AngularJS), that happens to get its data from an server api (node.js), then you will begin to understand how to properly use the MEAN stack.
First: Angular will have the routes defined in the $routeProvider. Build the routing urls in AngularJS first. They are "THE" routes for your web app. A good way to look at it is to build the AngularJS portion with the ability to change your api server, even to another language (PHP, python, go, etc) if necessary.
Second: Build your AngularJS to communicate to the api with $resource. Essentially a $resource is an easy way to call out to an api using restful routing. This "restful routing" is now the routing that needs to be "mimicked/copied" into the routing for the node.js routes.
Often the AngularJS routes (the url) will match the $resource routing that matches the node.js routing.
Again, take a look at meanjs.org and you will have a better understanding on how to properly organize what "seems like" (and actually are) two separate apps.
Basically, you need three sets of routes (or two if you are doing it on the cheap).
Start out with a set of routes on the server that return regular webpages. Forget about JavaScript. Do not involve Angular at this stage.
Second, add another set of routes on the server which return data in a rawer form (such as JSON). This would typically be a RESTful API.
Third, add Angular to the client. When the view needs to be updated, update the URL in the browser and use Ajax to hit the RESTful API to get the data needed to populate it. (You want the URL you set the address bar to to match the URL of the page from the first set of routes that you are duplicating with JS and the data from the RESTful route).
If you are doing it on the cheap, like Gawker did, then you would skip the first set of routes and go direct to the JS+REST approach.
I think you need CMS on MEAN stack development environment.
there are some cms on mean stack you can try.
PancilBlue
Calipso
try this.
I was trying something similar, I found this link very useful AngularJsCMS It has told about free respond cms which is based on angularjs and have the ability to create pages like wordpress and manage contents.
We have been working on a project using angular and keystonejs. Simply serve the default template layout found in keystone and inject the data-ng-view tag within the body tag. Serve this template for all requests to '/'.
Then write your angular app normally to consume endpoints. These endpoints can be done in keystone using the api middleware. In the routes/index.js file add a key/value pair in the routes object with the name of your custom endpoint then import the folder containing your endpoint function definitions.
var routes = {
views: importRoutes('./views'),
api: importRoutes('./api')
};
exports = module.exports = function(app) {
app.get('/api/posts', keystone.middleware.api, routes.api.post.index);}
I recently migrated my blog over to MEANie - a lightweight custom MEAN Stack CMS that I developed.
I made it open source for anyone to use and posted details and setup instructions on my blog at http://jasonwatmore.com/meanie.
I'm wondering if it's possible to trigger a route and show a different view in Angular without updating the URL.
Basically I am embedding an Angular app inside an existing web site, and I don't want my embedded app to alter the URL, but I do want view management via routing.
I understand I can use ng-include as suggested here, but I would rather use routing.
I don't think it's possible to use routing and not URLs. You can roll your own routing pretty easily using ng-switch and a rootScope variable which stores the current "route".
The ng-include approach would address your issue. I'm not sure what you mean when you say you'd rather use routing since routing by definition uses URLs, but, yes, you can load different views using a different mechanism. Take a look at Angular-ui ui-router which uses the concept of states and views in addition to routing. It sounds like the view mechanism in states might address what you want.