index.jsx starts before companion index.js finishes initializing settingStorage

[JakeScott]

When my watch face companion app starts for the first time, it needs to set up settingsStorage. In the simulator, it seems like index.jsx starts up about the same time as the companion starts, and often it tries to access things in settingsStorage that the companion app hasn't finished initializing.

Is there a way to make index.jsx wait until the companion index.js has finished setting up settingsStorage?

[JakeScott]

I think I solved the problem, the index.jsx was doing some initialization as well, so I took all of it out and moved it to the companion index.js. Now the index.jsx has nothing but the settings controls. I guess that's the way the system is designed - all the code in the companion, index.jsx is just the GUI.

[JakeScott]

The index.jsx works better now, but one settingStorage.getItem() still sometimes returns null, when it should have a value that was set up in the companion app. Also, it looks like the index.jsx is run every time the companion does a settingsStorage.setItem(). Not a problem, but it would help to know the sequence of events with the companion and the index.jsx. Previous version had one large, fairly complicated object with many settings in it that I was doing a setItem() with, but that required many complicated JSON.parses in index.jsx. That seemed to cause problems, so I broke down the large settings object into many (11) individual settings, doing a setItem() for each in the companion, and a getItem() for each in index.jsx. One item is a list of settings theme names (themeList), so it can't be broken down. That's the item that seems to cause problems - sometimes it is "undefined" in index.jsx when the companion should have set it. Are there practical limits to the size and number of items that settingsStorage can handle?

[Gondwana]

Bear in mind that JSX is not straight JS. It's 'React', and parts of it do indeed react to value changes. Have a read of the 'react' documentation — and then explain it to me, please! 🙂

[JakeScott]

I did read some of the react documentation - and didn't understand most of it , so I'm no help there. But I did discover two things about settingsStorage that explain the problems I was having. These might be helpful for others: if you do a setItem on settingsStorage, but the value of the setting didn't change, it does not trigger the settingsStorage.onchange in the companion. I was using it in a button in index.jsx to trigger the onchange in the companion, but it didn't work until I made sure the value changed every time (used a random number generator for the value, because the actual value of the setting didn't matter, it was just to trigger the event).

The other thing I realized  (which was critical!) is that every change to settingsStorage in the companion causes the index.jsx to run again. So you might need to consider what setting(s) index.jsx has to have initialized before it can run, and be sure to do the setItem for that one first, because that will trigger index.jsx to run. Or redesign index.jsx so it's tolerant of temporarily missing settings. If there are more than one settings that index.jsx needs, you may have a problem, because index.jsx will run on each setItem, and possibly fail on the first one. That's why I was seeing index.jsx run before the companion finished - it was running on each setItem call, and blowing up because it needed something in later setItem calls that hadn't happened yet. Index.jsx needs to be only a GUI - with as little logic in it as possible.  JSON.parse calls in index.jsx were a problem, because they would blow up if the value didn't have a valid JSON object in the setting yet. I put a try/catch around the JSON.parse calls in index.jsx, and ignored the error in the catch if it happened, because I knew when the companion got around to doing the setItem for that item, index.jsx would run again and then that parse would work. Moral of the story is that index.jsx needs to be tolerant of temporarily missing settings if possible.

Know that index.jsx will run on every change of settingsStorage, and as long as nothing causes a error that aborts it, all will be good after all the setItems have finished.

Also - keep the setItems values short and simple if possible. Originally, I had one large, complicated settings object, converted to JSON, that I was doing setItem on (settingStorage items must be strings only - not objects!). It took so long to stringify and do the setItem in companion, that I think index.jsx would sometimes start running before companion was done with the setItem, causing the JSON.parse to fail in index.jsx. And I was doing just one setItem, so if index.jsx blew up - settings didn't work at all.

[Gondwana]

Useful info; thanks. I didn't realise that the .jsx code didn't get triggered if the relevant value didn't actually change.

I also assumed that only the relevant bits of the .jsx were re-executed when a particular setting changed. I never thought to test this; you've done more investigation that I have.