Supports local storage and provides runtime methods for both front-end and back-end

[misitebao]

In Runtime in v1, Store function is provided for state storage and synchronization, I think this is a good function, we should provide such a function in v2.

Although the localstorage of the front-end part can also provide the function of local storage, I personally still insist that the front-end part is only used for view display, such as data processing, communication, and storage, which should be done by Go, not all The functions are all done by the front-end part, and the wails are only regarded as the shell of a web application.

[leaanthony]

Storage wasn't really adopted by the community and it was hard to get right without generics. We might look at it for v2.2+

[kcmvp]

Should give the choice to the user, it can use any database he likes.

[leaanthony]

Ah I wasn't talking about local storage, but the stores feature of v1

[sdzyba]

Totally agree on a need to have a backend storage functionality.

Indeed it seems that right now the only way to store anything is localstorage on frontend side, but backend might need the storage in the first place to expand/initiate the data. That leads to a non-practical approach where frontend reads from localstorage, passes the date to backend, receives the response and only then is able to operate.
Whereas it'd be much more straightforward to store and process the data on backend from the beginning.

[leaanthony]

Why do you need to use localstorage? You can save anything in Go by just calling a method and passing in the data. There's a lot of considerations for a frontend file save API, not to mention the security aspect. There's nothing stopping you from saving to disk via Go, and that's the appropriate approach.

[sdzyba]

Well yes, it's doable. But would be helpful to have such a cross-platform storage functionality included in the framework.