Open joeblew99 opened 7 years ago
Yep! Webviews are definitely on my todo list and should not be too difficult.
I have been playing with web views and golang a bit for mobile and desktop.
For Mobile i have found that being able to have a JS <--> golang bridge is valuable. Also because you want to be able to fire notifications and call other native stuff via golang. BUT you also want to be able to call it from inside your SPA web view too.. SO you can write JS, and make a call that goes out to golang (via protobuf since this is matcha) and then matcha call the native stuff to make , for example, a local notification.
The reason i am raising this is because it wil allow us to deploy apps without going through the app store because its just JS ( react web ) running your web gui, and if you change the logic of it (lie add a notification Or a deep link ) you DONT have to redeploy binary code.
The same is true for pipelines.. You can run otto js VM in your mains golang code and it can model pipelines, calling down to the golang code. Its very useffil, and because its JS i can update it as i need to without going through the app store.
The pipelines actually creat the viewModels that web GUI uses. This means that the react web stuff needs no saga's or reflux at all. Each react view has a Materialised view just for it from the golang code waiting to be used. Also no reflux is needed because all changes are pushed to the React layer localyl via web sockets. The golang code can be a service on the phone..
Hope you dont mind me adding my 2 cents here ??
Because all all the plumbing you have it will be pretty easy to also expose a webview ?
I only suggest this because at the moment, you have access to native types for GUI's and thats great, but there are also times when you want to just code use web and have it run on all mobiles with an agnostic GUI.
I have been following this project for ages and i like the way the protobufs are used. Its really the first approach that i feel is sustainable for golang GUI's