This is a pretty newbie question. However, in EmberJS, I've found that both of the methods work for linking to the blog page in my application.
<p>{{#link-to 'posts'}} See my blog{{/link-to}}</p>
See my blog
Is it better to use {{link-to}} in EmberJS? How come?
The difference is that the {{link-to}} component will navigate to the specified route within the current running Ember application, while <a href="posts"> will do a new browser request to that location and re-start your Ember app at that route. You should use {{link-to}} since you'll be using the Ember internals to navigate within your single-page application and it will be a smoother user experience.
While they both can work, watch your browser closely and you'll see the anchor tag will give you a page refresh and re-launch your Ember app (though in the right location). Using a {{link-to}} will feel faster since Ember is presenting the new page via javascript rather than restarting after a page refresh. It's the difference between navigating within a single-page application, and jumping into a SPA from an external page.
While Ember does render an anchor tag in place of the {{link-to}} at run-time, it interjects to stop the default anchor tag behaviour. The docs explain it like so:
By default the {{link-to}} component prevents the default browser
action by calling preventDefault() as this sort of action bubbling is
normally handled internally and we do not want to take the browser to
a new URL (for example).
(from https://emberjs.com/api/classes/Ember.Templates.helpers.html#toc_allowing-default-action)
Also, with the {{link-to}} component you can pass a model directly into the route. This is a bit more advanced, but the Ember guides have some good examples.
https://guides.emberjs.com/v2.13.0/templates/links/
Related
If I'm on a page in my Ember app, and edit the URL manually or use a bookmark that identifies another route within the same app, by default the page gets reloaded, losing any transient state it had, rather than just transitioning as it would have if I'd followed an Ember-controlled link within the app. Is there a built-in feature of Ember that's well integrated into its routing features which can prevent that and just transition instead?
Details:
With Ember's default routing, the URL itself changes rather than just the fragment identifier ("hash"). E.g., in the Quick Start example, if you're on http://server/scientists and want to look at the list of programmers instead, you go to http://server/programmers.
If you do that by clicking a link handled by Ember, that works within the loaded page just fine (I'm assuming Ember uses the History API under the covers to replace state without page reload). No page reload is caused.
But if you're on http://server/scientists and click a bookmark to take you to http://server/programmers (or edit the URL manually), it reloads the page, losing any transient state the page contained.
In contrast, in an app that uses fragment identifiers for routing (like Gmail), the equivalent change of (say) http://server/#scientists to http://server/#programmers does not cause page reload, even if you manually edit the address bar or use a bookmark. (Of course; it's just a change to the fragment identifier, not the actual URL.)
Is there built-in handling in Ember that's well integrated into its routing features that can make it handle that use case without reloading? Either by using a fragment identifier instead of changing the URL, or with some History API feature? (Although I can't think of a History API feature that could do it.)
In config/environment.js file, include ENV.locationType= 'hash'; by default it would be set to auto.
For more information - http://emberjs.com/api/classes/Ember.Location.html
I've a generic route /login that displays the login form inside a modal. Now I want the content behind to remain the same of the previous url.
How do you go about this?
Thank you
Trying to implement login modal form as a generic /login route is probably not the best option, as it does not go well with the way Ember routes work, which can be summarised as follows:
Given url is matched to (possibly multiple nested) routes.
Each matched route resolves it's model and then renders corresponding templates to appropriate outlets. Templates for previous route are wiped out.
Navigating to generic /login would wipe out the templates rendered by previous route - namely there would be no content in the modal background (see also related question).
I would suggest either:
Not rendering /login route in modal dialog, but instead in the main app outlet, and only then redirecting user to the previous route. UI experience is probably not much worse as user probably does not need any information from the modal background anyway.
Instead of having generic /login route, you could use query parameter, e.g. ?should_login=true on ApplicationController which would render login modal in appropriate outlet. This way primary application state would still be encapsulated in the route url, thus templates for the previous would be properly rendered in the modal background. Suggested approach on how to handle modal dialog can be found here.
I've done some example apps in Ember, and now I'm ready for using it in existing application. Its traditional web application (request-response, full reload and some ajax loaded content, no rest/api things)
So lets assume I've few page (urls) like
1 abc.com/home.php
2. abc.com/support.php ,
3. abc.com/support.php?call=meeting
and so on..
so is it possible to use just one url with ember app and rest leave as such untill its ready?
PS: I did try for support.php as this.route("support",{path:"/support.php"}) and have SupportController and support.hbs template but its not working. I'm not sure how to put it in jsfiddle.
Thanks
Include your ember app only on the page that needs it, so only on abc.com/support.php
As far as ember can see, when you go to abc.com/support.php you are on the index page (of the ember app), and you will need to use the index.hbs tempate.
I had the following idea: my page at example.org serves classic HTML from the server. Besides, EmberJS is loaded, too, and waiting to come into action:
as soon as somebody hits an ember route then, for example example.org/#/login, the current should be replaced by what the view renders for it. From then, the whole app should serve as one-page-app.
Is that a good idea? Anyway, I don't know how to get that started. Overriding View's appendTo method or setting the rootElement property as in http://emberjs.com/guides/configuring-ember/embedding-applications/ does not suffice because if that were the body, the view output is just appended there…
If your entire Ember application requires a user to be logged in, it is valid to have two separate "apps":
A regular non single-page application (server-side using rails, PHP or C#) with a sign up and login pages
A single-page application (i.e. Ember) send as soon as the user hits the login button in your regular app
You will have 2 index.html pages, one for each application (and it's okay to do that!). The URL of the Ember App could be under example.org/app/.... You will need to configure the router of the regular application to server your Ember App for all URLs starting with /app/.
Does that help? :)
I am creating an Ember.js application which basically has a very simple UI: header, content, footer -- all this in the application layer.
But, when you see the site at first, you have a hybrid application -- google needs to reach parts of it, but login, registration, dashboard, and other pages, should be handled by Ember.
And I might have a bit of an issue, because if I render some views, say on the homepage, in some outlets, then those outlets are going to be different after login, on the user's dashboard.
I cannot show off the UI, but i could try to provide more details if needed.
My question would be how to handle this issue?
I used a bit of a hack for now: just before Ember initialize, I remove from the DOM the content rendered server-side.
This might be ugly, but it works. This way robots may reach the content I want them to reach, the users on the other hand will see something better.