View Full Version : applyState not being called automatically for stateful objects in 4.2

Patrick Bennett
5 Aug 2014, 8:42 AM

I've looked at all the example code for state management and I am still not having any luck. getState() gets called and I see the values I want in the cookies but applyState() never gets called. I've hooked up a tab panel and a combobox and neither works.

I am doing this in SA:

channel: 3.0.1-stable
framework: Ext JS 4.2.x

In my app launch:

Ext.create('Ext.state.CookieProvider', {
expires: new Date(new Date().getTime()+(1000*60*60*24*30)) //30 days

And this is my combobox:

xtype: 'combobox',
getState: function() {
return {
value: this.getValue()
applyState: function(state) {
console.log('applying state');
stateEvents: [
stateId: 'io_advertiser',
stateful: true,
itemId: 'select-advertiser',
fieldLabel: 'Select Advertiser',
displayField: 'name',
store: 'AdvertiserStore'

I never see the console.log of "applying state".

Any help would be appreciated.


11 Aug 2014, 8:58 AM

The getState, applyState, and stateEvents configs / methods are already covered for you with the ancestor Ext.form.field.Text class so you won't need to define those yourself in the combobox's config.

See the example below:


Patrick Bennett
11 Aug 2014, 10:35 AM
Thank you for your response, but that doesn't address the issue. It works great for a drop down that's backed by an in-memory store, but when it loads from the server I think it doesn't work. The state is applied to the drop down before the store has actually loaded. It seems like state management doesn't work when there are significant load time issues because state gets applied too early. Unless there's something I am missing.

I am thinking I am going to roll my own solution with cookies that waits for the store to load and then selects the value in the cookie and see how that works. I need to have the values for the drop-down come from a server side store because the data in the drop down is actually a list of clients that can grow over time. I just want my team to be able to start with the client they were last working on, hence the need/desire to track that on the client side.


18 Aug 2014, 2:43 PM

I believe you will have to roll your own solution at least to some degree. The statefulness of components is only designed to work with in-memory/browser data as the statefully supplied configs are applied on top of the instance config at instantiation. The framework doesn't offer a way to pause instantiation and fetch the configs from a remote source.

What some users have done is use a localStorage stateful provider instance and before the application renders they'll fetch the user session data from the server and push it to the local storage provider. Once the response is processed then the application is spun up and the components are loaded with server-furnished configs from localstorage as if they were there the whole time.

But, with that sort of a setup you'll still have to listen to the stateful events and save them up to the server so still a rolling-your-own-solution process as the only stateful providers in the framework are cookie and localstorage.

Patrick Bennett
18 Aug 2014, 3:12 PM
That makes sense. I think after reading your response I might see if I can get the team to bite on creating a new endpoint for this data and turn it into a real settings service. It would be great if this data could be universal regardless of what computer you are on, and we just ran into an issue with multiple people logging in to the same computer, which would be obviated by a server-side profile solution. Just wipe out all settings on logout and download fresh settings on login. I would just need to have the final setup of the application wait until the user profile service finished loading. Then all layout information could be calculated based on your last session like active tab, sorts and filters, etc.Fun stuff if I can shoehorn it into the schedule!

18 Aug 2014, 6:49 PM
For what it's worth, I did something somewhat similar on a previous project I worked on where we needed data from several sources to roll in before the app would launch so initially you'd have a login window and once logged in it would fetch the data based on what role the user had and such and once that was in hand we'd execute the Ext.application call and the login data retrieved would be rolled into the application launch. In the meantime there was a loading indicator with fetching dataset 2 of 5, 3 of 5, and so on so the wait time was justified in the user's eyes - I hope. :)

It wasn't a user preference type thing - was a role-based application setup, but certainly could have been user preference. Another way you might consider going if you're thinking of going that route is to use the ViewModel classes in Ext5. The ViewModel data applies behind anything that is applies statefully so actually works to your advantage there I'd think. And any data served to the top-level component (commonly a Viewport instance) is fed to all lower components in the hierarchy under that top-level component automagically. Makes setting role-based components very easy by passing in a settings data blog on top of the Viewport and having the underlying components auto-configure based on that top-level dataset.