The Context:
I just updated an Ember App from 2.16 to 2.18.
The Situation
In our code, we are manually cleaning up one of our models data by doing:
store.unloadAll('myModel'); inside an ember.run, the code looks like this:
Ember.run(function() {
store.unloadAll('myModel');
});
and I am seeing some ajaxs calls being made to the .../myModel endpoints.
The problem
I cannot explain why those ajax calls are being done.
What I have tried
I am running the store.unloadAll('myModel'); outside of the Ember.run block, and not seeing the issue any longer, however, I really would like to understand why this is happening.
Related
I am just getting started with unit testing in Flutter, and I have hit a bit of a wall. I have a fairly simple app located here:
https://github.com/chuckntaylor/kwjs_flutter_demo
The app is essentially a list view of events where you can tap on one to read more details about the event.
I have two screens for this: events_screen.dart for the list view, and event_screen.dart for the details. I have been trying to write my tests in events_screen_test.dart
My testing difficulties are with the events screen (the list view). After running await tester.pumpWidget(MaterialApp(home: EventsScreen()) I can use find.text('Events') for example to find the title in the AppBar, but I cannot find any of the elements that make up the list.
To clarify further. I am using get_it as a serviceLocator to get the viewModel for the EventsScreen when it loads. The viewModel is the ChangeNotifierProvider, and EventsScreen contains a Consumer to update the list. in EventsScreen initState(), it calls loadEvents() on the viewModel. After loadEvents() is done, the viewModel calls notifyListeners(), so that EventsScreen can update.
How do I ensure that all these steps occur so that I can properly test if the EventsScreen is rendering properly?
I could be approaching this all wrong, so any advice is appreciated.
I have solved my problem, but perhaps someone can shed some light on this. In the end I executed:
await tester.pumpWidget(MaterialApp(home: EventsScreen(),));
// followed immediately by this second pump without arguments
await tester.pump();
At this point, the Widget tree was complete and I could create Finders as I hoped and could run all my expect statements without issue.
I am not sure exactly why this works though.
As you saw calling tester.pump(), after tester.pumpWidget(), do the job. This works for the following reason: you wrote you are using a Provider, and you run a notifyListener after the data are fetched. Now in a normal application run, you see the widget rebuild since you are using a consumer to that provider. In the test environment, this does not occur if you don't explicitly call a "time advance". You can do it calling await tester.pump() (as you did) and this asks to run a new frame on screen, so now you have your list rendered.
Please see follow-up question here here where it gets to the meat of the problem.
I am making an ajax call that reloads the data in the local storage of an Ember App. I am calling localStorage.clear(); right before the ajax call. However, after the ajax call, nothing is cleared!
The printout localStorage.getItem("model-emberjs") right after the clear() and is null as expected.
The printout localStorage.getItem("model-emberjs") right after the ajax call that follows has everything from before.
I'm using the LS adapter.
Do you have any idea why?
P.S. I don't know how to make ajax call work in jsbin so sorry no live example.
As #Benjamin already mentioned I also believe you have a caching problem. If you are using chrome try to disable the cache while developing by bringing up the extra settings dialog:
And then enable "Disable cache":
Now try again to call localStorage.clear() it should work this time.
Hope it helps.
I understand that ember-data is still in a fairly unstable state. I just would like to confirm that what I'm experiencing is expected behavior or a bug. And hopefully find some manner of work around.
I have an application that functions correctly in every expected way except one. Best I can tell I've traced it back to way the application routes on initial load. If I start the application from a route #/posts or #/post/1 where the id is valid it works fine. Application starts, routes, and loads the model. Any valid route works fine. If I were to use a route with a bad id #/post/1a534b where ember-data will not be able to find an underlying model with that id, the application never routes.
I've enabled LOG_TRANSITIONS on my application and confirmed it never transitions to a route, doesn't error on routing, never even injects my application template into the DOM. This problem is unique to initial load as it seems to wait for the model to load before injecting. This never happens because the promised model doesn't exist.
So is this expected behavior or is something else at play here?
I will say that my application isn't loaded til after dom ready and is pulled down async on dom ready. This shouldn't make a difference as the application runs fine when loaded with a proper route.
In the mean time I'll see if I can get a jsfiddle as an example since I can't use my code directly.
Unfortunately I believe this is expected behavior at the moment:
https://github.com/emberjs/ember.js/issues/1454
I think there is work being done to address errors and the router in general here:
https://github.com/emberjs/ember.js/pull/2740
In the route, transition to another route if the model fails to load.
model(params) {
return this.store.findRecord('account', params.account_id)
.catch(()=>{
this.transitionTo('admin.accounts');
});
},
I'm currently building an app with Ember 2.10.0
Just digging into Ember JS and read through a great guide at http://trek.github.com/ regarding the use of the routers and structuring your ember app. The framework is great and has come a long way based on some of the early tutorials.
My question is, does any one have any strong opinions/good examples/best practices for updating a instance of a controller that was initialized by the router and the connectOutlet method:
connectOutlets: function(router,context){
router.get('applicationController').connectOutlet(
'attlist',
'smartSensor',
App.SmartSensor.getSensorData(context)
);
}
The SmartSensor model's getSensorData() function calls out to a back-end REST API. I would like to then periodically poll the server to see if the attributes of the controller have been updated and if needed update the controller. I can think of a few ways I could force it, but nothing that seems clean. Any ideas or am I overthinking it?
Thanks!
I would either:
a) Create a new poller object and give it a reference to the smartSensorController. The router would call startPolling() on the poller in your connectOutlets method, and call stopPolling() when leaving the state where it is needed (assuming it ever becomes unneeded in your app)
...or...
b) Let the smartSensorController take responsibility for polling. After your call to connectOutlet, do router.get('smartSensorController').startPolling() and a corresponding stopPolling() at the appropriate spot in the router.
Hope that helps!
I'm used to thinking about a single-page application startup happening like this: 1. Bootstrap some data into critical models, 2. Instantiate a master controller, and 3. Call it's render() method to kick things off.
How is this accomplished with Ember? Following the (meager, sigh) examples in the documentation, it seems like things sort of kick off on their own when the page loads -- templates are compiled, views render like magic when the page loads. I feel like I am missing something fundamental. It there an example online of a more complex app, say something with tabbed or dynamically loaded views?
Lightbulb, going off it is not.
I've started a blog series about getting up and running with Ember on Rails. Here's Part 1:
http://www.cerebris.com/blog/2012/01/24/beginning-ember-js-on-rails-part-1/
I hope you'll find it useful, even if you're not planning to use Ember with Rails. Most of the interesting details are client-side and thus server-independent. The posts so far cover creating an Ember.Application object, loading data dynamically through a REST interface, and then rendering an Ember view on a page in handlebars. I hope it's enough to get you started.
When you extend an ember Application object you can provide a ready function which will be called when the application starts. You have to make sure to call this._super() or else it will break your application. Check out my sample sproucore 2.0 application (ember is the new name of sproutcore 2.0).
The way that ember works is that it sets up a run loop which responds to events. Whenever an event fires, the run loop basically calls the necessary handlers and runs any bindings that need to be updated. Since everything typically happens in the run loop you often don't really write any code to update things. Instead you write bindings which are fired when needed.
Another thing I've done is use an Em.StateManager to bootstrap.
App.Loader = Em.StateManager.create({
start: Em.State.create({
enter: function(mgmt, ctx) {
// this code will execute right away, automatically
}
})
});
Since you use create instead of extend, the object will be instantiated immediately. If you define a state called start, it will be recognized as the default initial state (or you can specify another one by name). So the new StateManager object will immediately enter the initial state, and when the StateManager enters a new state, it will always look for a method of that state called enter and fire it if present.
A state manager is the natural place to initialize your app because the object provides ways for you to micromanage execution order during an async loading process without entangling yourself in too many callbacks.