I have quite an interesting problem.
We have Rails + Capybara performing integration tests with our Ember frontend.
The issue I'm having is, when running our :Selenium powered tests, SOMETIMES (and this is the crucial bit, it's sometimes), a UI element will be pressed and the Ember action will NOT fire.
So, This is NOT an ajax related issue. I'm not getting a data error. Nor an Ember error, nor a js error, nor a Capybara::ElementNotFound error.
The UI in question has loaded, Capybara then successfully clicks on the button, and then the Ember action is never called. It's not that it's taking too long to respond, it's simply not triggered.
I know this because I'm logging the Ember actions (console.log()) and can see it happen when it works, and not happen when it doesn't.
So, my theory is... Ember has loaded the UI before it's setup all the js to handle the actions. Could this be possible?
Have you tried explicitly triggering the run loop in your tests?
Figured it out.
It seems as if the Ember templates, and thus UI, will load BEFORE all methods in the setupController property in Routers is complete.
I don't really know enough about Ember to understand how and why this works like this, but I was able to fix this issue by doing the following:
At the end of all callbacks in setupController I set a controller property to true. 'controller.set('setupDone', true)'
In the template for that Route, I wrap the UI in a conditional {{#if setupDone}}
Related
In our Android app, I initialize the React Native JS code as soon as possible, because I have some JS code running in the background, even when no React Native views are currently visible. I do this by calling ReactInstanceManager#createReactContextInBackground().
This works, and the JS code gets initialized, but it appears I cannot call any Java methods annotated with #ReactMethod until I have actually opened a React Native view that calls ReactRootView#startReactApplication(). If I attempt to call any native methods before that, nothing happens, but it seems the calls get added to a queue and then eventually get picked up when the React view opens.
It appears the same thing goes for timers set with setTimeout(). They just don't get called when no view is open yet. So it seems the JS gets evaluated, but then the JS engine isn't "running" yet.
How can I make sure the engine is properly running before opening any React views?
Let your first RN View call a #ReactMethod that will set a flag in Java. Have your Java code not execute anything until the flag is set.
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 learning how to use EmberJS by doing the introductory tutorial form the "Getting started" page. However, when I get to the "Accepting edits" part, I have a bug:
Uncaught Error: Attempted to handle event `willCommit` on <Todos.Todo:ember304:3> while in state root.loaded.updated.inFlight.
The call to Todos.TodoController.acceptChanges() seems to be triggering that error. The part I'm referring about is this one:
http://emberjs.com/guides/getting-started/accepting-edits/
After reading up on model lifecycle in Ember - http://emberjs.com/guides/models/model-lifecycle/#toc_in-flight - I still don't get why this bug appears.
One work-around is to save the model each time it changes (so every time the value of the <input> changes. Which works fine but would probably perform poorly with a HTTP API (as opposed to fixtures).
Could this be due to BC breaking changes in the ember-data lib?
What else could cause this?
Versions of libraries I've used:
jQuery: 2.0.3
Handlebars 1.0.0
EmberJS: 1.0.0 RC7
Ember Data: v0.13-102-g6bdebe7
After reading up on model lifecycle in Ember - http://emberjs.com/guides/models/model-lifecycle/#toc_in-flight - I still don't get why this bug appears.
This is not a bug, the in-flight section say's it all:
A record that is in-flight is a dirty record that has been given to the adapter to save the changes made locally. Once the server has acknowledged that the changes have been saved successfully, the record will become clean.
This means that you are trying to change the record while a previously change made it dirty and a possibly call to this.get('store').save() is still in the doings e.g. waiting for the server to respond. During this time frame you can't make changes to that same record without getting the error.
So a solution could be to not trigger this.get('store').save() after a character of the textbox has changed but rather on focus out for example, or even with a explicit button to save the record which you could disable until your server acknowledges it's change, this would not make a request for every character to the server resulting in sluggish performance due to some latency. Hope this makes sense.
Hope it helps.
I had this same issue with the Getting Started guide. I solved it by checking if the model was currently saving in acceptChanges:
acceptChanges: function() {
var model = this.get('model')
if (model.get('isSaving')) { return }
this.set('isEditing', false)
model.save()
}
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.