I need the ability to programmatically route to different pages. As far as I can tell the only way to actually render a route is from within the Route declaration as such:
Router.route('/', function() {
this.render('index');
});
What I'm looking for is the ability to from some arbitrary part of the code to transition to another route. i.e. if(whatever) Route.transionToRoute('homepage');
I by snooping around found that I could use Router.dispatch, but I got some buggy behavior that I believe originated from that usage, in addition I got some strange debug warnings in the console. It appears to be an internal method as I can't find any documentation on it.
Can what I've described be done with iron router?
Thanks for any help :)
Router.route('/', function() {
if(this.ready()){
if(Meteor.user()){
this.render('news');
}else{
Router.go('register');
}
}else{
this.render('loading');
}
});
It's pretty straightforward, first it waits for this.ready() if you have any subscriptions to be called, then if you are logged in (Meteor.user() object is available) it renderes news, otherwise it go to register path
If you are inside the route controller, you can call:
this.redirect('routeNameOrURL');
If you are anywhere in you application, you do:
Router.go('routeNameOrURL');
Both will pop a new state to the browser history.
You can check Iron Router official Guide for details:
https://github.com/EventedMind/iron-router/blob/devel/Guide.md#using-redirects
Related
I'm trying to figure out how to call an Electron method from my frontend application javascript. Either the main or renderer process would do fine for starters, presumably I can work through the rest from there.
In all the examples I can find, the renderer code attaches to the frontend element and adds an event listener:
document.querySelector('#btn').addEventListener(() => { // doElectronStuff });
This is not quite what I'm after though... it seems like a rather severe coupling to have this "server side" code reaching into my DOM.
Using an Angular2 frontend, I found what appears to be a nice package called ngx-electron which exposes the electron interface as an injectable complete with typescript mappings, etc.
So now I have an Angular service that I want to call an Electron method for (to grab some database stuff, or whatever else):
constructor(private _electron:ElectronService) {}
getAll(): Entity[] {
var results = this._electron.ipcRenderer.?????
}
I really have no idea how to make the angular service make that call to the electron method. I've tried running emit() and have tried using send() and such against the ipcRenderer, the remote.ipcMain, but receive various errors and all and all can't seem to make the connection.
Hopefully I missing something simple? What's the combination of electron-side syntax and angular-side syntax that's required to match these up? Thanks
(I'm not particularly stuck on ngx-electron, but it did seem a nice lib and I'm assuming it works well, once I get past my own block...)
Found it. As usual, an oversight on my end.
// in the angular service
this._electron.ipcRenderer.send('event-aka-channel-name1', args);
// in the electron main.js
ipc.on('event-aka-channel-name1', (event, args) => { // doStuff });
My issue was apparently a misspelling of an import which I caught via various logs. Once that was fixed the rest works as intended (or at least enough for me to move forward)
I am asking this question because I am a bit confused. I just started to discover meteor ( better late then never ) and I am reading/hearing a lot of discussions why I should use Flow-router instead of Iron router.
I started my project with Iron router, but the more I read the more I think I should switch to Flow-router for many performances, rendering reasons ...
What pro's and con's make them different?
Sank U !
The official documentation recommends FlowRouter: https://guide.meteor.com/routing.html
But you can use iron router too. I have already used them both in different projects, but I decided to follow meteor official recommendation.
I use IronRouter, because the description states that
"FlowRouter only deals with registration of subscriptions. It does not
wait until subscription becomes ready."
(https://github.com/kadirahq/flow-router)
Because of this, when you subscribe to large data, you get extra page updates or failures. So I chosed IronRouter, which in the documentation describes how to make the waiting for the subscription ready (WaitOn). It works without problems 2 years for me. From the point of view of the update, both routers have not been updated for a long time, more than a year, so it is unclear whether the revision is coming as new versions of Meteor are released.
Press F12 in browser, watch for any errors. In my case I removed a package, but did not remove the code calling that package.
It errored, and looked like Iron Router was to blame.
Removed the offending code loading some other lib I removed and hey, Iron Router works.
The problem with FlowRotuer is you have to jump through hoops to load data into a template.
It makes code complex, fragmented and hard to follow (My opinion).
Iron Router allows you to pass data in as a second argument to the render function and access it directly from the template.
With Flow Router you have to first write data to a session, then write a Template helper to pull the session data or wrap your template in a "with" element.
This is an example how FlowRouter would have you get some example into a template
Template.templateName.onCreated(function() {
Meteor.call('thirdPartyAPI', function(error, result) {
Session.set('result', result);
});
});
Then on the template side you could have:
{{#with result}}
Content that requires a context
{{/with}}
And you would have a template helper that returned the Session/ReactiveVar, e.g.
Template.templateName.helpers({
result: function() {
return Session.get('result');
}
});
A similar example with Iron Router
Router.route('/post/:_id', function () {
this.render('Post', {
data: function () {
return Posts.findOne({_id: this.params._id});
}
});
});
Some background...
We have an ASP.NET app we're slowly converting over to EmberJS. We have a single Ember application we instantiate for certain portions of the site. As we migration pages they get routes in the Ember app. The goal is to have everything in Ember over time. In the interim, the user can click on links that take them back to ASP.NET portions.
Our issue is with resetting the state of the Ember app if the user either clicks back to go back into Ember or clicks on a new link that takes them back into the Ember portion.
We've tried calling .reset on the application, but doing so gives us an error saying the following. Our application is called ConsoleCli and not the standard App.
Library "ConsoleCli" is already registered with Ember
Moreover, we get the following error saying one of our modules has already been registered.
Cannot re-register: `location:history-js`, as it has already been resolved.
I tried wrapping my registration of the history module with a check, but that creates a whole other slew of errors
if(!application.__container__.lookup('location:history-js')){
application.register('location:history-js', HistoryJsLocation, { singleton: true });
}
I read https://github.com/emberjs/ember.js/issues/10310 and I think it means reset() is supposed to clear all registries once this has all been merged into the main branches.
Shouldn't called App.reset() right in the middle of using an EmberJS application just reset it with no issue?
Excuse my lack of understanding, we're just learning all of this as we go.
We're running the following versions
Ember 1.11.0-beta.2
Ember Data 1.0.0-beta.15
jQuery 2.0.3
TIA!
I think you might have run into this bug: https://github.com/emberjs/ember.js/issues/10310
Try the fix mutewinter suggests in that thread, it has worked for most people (involving myself).
Why does a TransitionAborted error get thrown when performing a full route transition when changing query params?
I am working off of the "Opt-in to full transition via refresh()" example provided at the bottom of the query parameters Ember guide (http://emberjs.com/guides/routing/query-params/).
The only change I made was to log errors:
Ember.RSVP.configure('onerror', function(error) {
Ember.Logger.assert(false, error);
});
Here is an updated JS Bin: http://jsbin.com/rerido/1/edit?console,output
If you click the "Change it" button, you'll see a TransitionAborted error thrown in the console.
I've been trying to upgrade Ember in my app from 1.7.0-beta.1+canary for some time now, but many of my QUnit tests fail when I run them all together. Most of my tests are fine if I run them in isolation. I suspect the TransitionAborted errors may be causing the test failures. However, I'm not sure if TransitionAborted exceptions are normal when performing full transitions. If anyone can confirm one way or the other, that would be very helpful in getting to the root cause of my problems, whatever they might be.
I was running into this problem too today. I'm using Ember 1.11.1 and Ember-data 1.1.1-beta.16.1.
In my case the change in the query parameter doesn't affect the model's data but another query. So what I ended up doing was removing the refreshModel: true from my parameter in the route code, and I added an observer on the controller for that URL parameter. So when the controller detected a change in that queryParam variable, the controller called the function I needed to re-query my secondary model.
I'm not sure if this would fix the issue if the query parameter is tied to the route's model, as I haven't tried that yet in my code. It looks like from the github link in the comment above that there's a confirmed bug with this somewhere, so I am curious how that will end up.
Bryan
I'm using the Router package from meteorite.
Meteor.Router.add
"/article/:id": ->
log "article"
"article"
Whenever the article page/template gets loaded, the callback function in the Router always gets run twice. I'm trying to use the callback function for incrementing the view count of the articles. So this poses a problem (every inc is done twice).
Is this the intended behavior? Or did I do something wrong?
UPDATE
It's actually not always being run twice. It happens when the page is refreshed or for the first time the browser navigates to the page. Regardless, it still poses a problem.
UPDATE:
The culprit is the HTML5-History-API package I'm using for IE 8+ routing support. The solution below will serve to help people with the same setup and problem.
Found a solution. But I'm not sure if this is the intended way for handling this.
"/article/:id": (id) ->
unless this.init
Session.set "articleId", id
Meteor.call "incArticleViews", id
"article"
If there's a better solution, please post it and I'll accept.