Thought I might finally weight in. I haven’t so far because I generally come around to eventually appreciating that whatever Wizard decides was actually the most thoughtful, even when my initial opinion differed.
While UI control values are scoped to the current pattern (by the current filesystem schema), I’m with zranger1 in that the most exciting use cases are across-patterns. One Pixelblaze is a trust zone similar to a domain, each pattern is like a page, so it kind of feels like I’m looking for the equivalent of Window.localStorage.
Common use cases:
- Setting a color palette that other patterns on the board will consume (e.g. in a playlist).
- Setting a speed, or fade-in/fade-out time for all patterns
- Setting a transform API argument (e.g the aspect ratio for rectangular matrices, or a current rotation angle)
- Receiving a value once from websockets and being able to store it for future patterns in a playlist.
This means I’d really like to support string-like names or keys so that accessing them across patterns is semantic. I imagine saveSlot(1, x) and readSlot(1, x) is not going to work well across my own patterns, but especially poorly if people are importing other people’s patterns from the library (unless scoped to the current pattern). I don’t necessarily want to add a string type to the lang, but maybe this is appropriate ES6-compatible interpreter magic; under the hood you could store them in the filesystem using the same string-ish methods Wizard uses to store named patterns and named controls (just not under each pattern’s directory).
You might consider namespacing weird board-specific concepts like a decaying flash ram, and using scary function names for things that eventually die:
Board.flash.burnItem(key, value)
Perhaps the board can store a global write count and disable burnItem() with an editor error when a threshold has been passed? Just throwing out ideas here.
I believe most flash on ESPs can handle 10K-100K writes before problems might show up, so preventing per-frame or per-render writing is really important.
Therefore, after following this line of reasoning to its conclusion, I think I’m in favor of a namespaced KV store that only writes values to flash on pattern-unload. Yes, you lose the values if you’ve changed them and the board loses power. I think this also makes the decorator or export persist var approach attractive. I do love memcached and Redis, and I generally capitalize singletons, so if not using an additional keyword or decorator, consider the less-magic:
BoardVars.set(key, value) // Only written to flash on unload
Hmm.
[quote="wizard, post:16, topic:1735"] If your code pushed a new state for a control, it would make sense to reflect that in the UI so that they were consistent. [/quote]
I actually asked for this a few times, as it’s been lovely in some other paradigms that supported 2-way data binding, state<->UI control. A common example of how this could be useful is when you import a pattern that has a default value for a variable controlled by a slider or picker: We’ve all experienced how the initial slider or picker state is commonly wrong on first import. Some sliders should start life in the middle of their range.