Svg #9
|
Datastar can also do pretty good with svg merging . where should I add this to the code ? It would be a seperate thing from the go comments things as you would not want to mix them I expect in the code or gui . |
Replies: 2 comments 6 replies
|
What's the use case for it? |
|
In my case I have diagrams and charts that golang produces as svg for diagnostics that need to be real time displayed |
|
thats exactly what I was thinking too. I think it's def possible, because i have done this with normal datastar and golang , so it should be possible with via. I am a bit overloaded so will not be able to help on this right now, so if you want to go ahead and make a basic example go for it for now. |
|
Nice! would like to try that for sure. Checked your repos and say you used https://github.com/ajstarks/svgo. Will take a swing at it some time. Seems promising. Any updates on the nats integration? |
I think any static svg is fine to get started. But yes that golang package can help with writing into the svg , and pushing up a change to the browser . A simple demo of changing the text in the svg using a text input box is a good way to get going . Nats stuff is here …. The demo is working , but might need to update to latest via release tag. The Readme explains what it does. Https is needed so I just use caddy for now. I am pretty busy but will finish it when work calms down. The taskfile is needed because it’s a little bit more complicated than other demos. anyways have a look if your curious. I am really happy with via btw. It makes it very easy to use Datastar and I will be making more contributions |
|
Just took a look at your persisted state implementation. Very interesting. A state persistence layer is super cool! But Im thinking it should be something external to Via, i.e. added on top of Via on a particular Via application. My reasoning for this is that Via should stay as minimal as possible and just worry about UI, signals and patching. Dead simple. The state can come from anywhere the user sees fit, but it should not be directly coupled to the Via runtime. I can totally see your broadcastable state store be a dependency injected into a via page init func. e.g. func pageWithLiveStore(store *myLiveStore.Store) func(via.Context) {
return func(c *via.Context) {
// setup normal via stuff and wire in the state from the livestore instance
}
}
// (...)
mystore := myLiveStore.New()
v.Page("/", pageWithLiveStore(mystore))Something like this would still function as expected, and makes way more sense to me. It adds functionality without making via concern itself with things out of its scope. |
|
sounds good to me @joaomdsg For me sessions being distributed using nats was very important , so that users can hit any server in any region. I will wait for you changes and try to adapt it to dovetail ... You can also use SQLITE for sessions and anything else too. https://github.com/litesql does SQLite replication using NATS, so can also use that. It uses LWW logic. https://github.com/litesql/pocketbase-ha is even better as you get all the Auth features for free, and real time subscriptions of Pocketbase SQLITE changes firing into into Via. Very nice to use. |
Just took a look at your persisted state implementation. Very interesting. A state persistence layer is super cool! But Im thinking it should be something external to Via, i.e. added on top of Via on a particular Via application. My reasoning for this is that Via should stay as minimal as possible and just worry about UI, signals and patching. Dead simple. The state can come from anywhere the user sees fit, but it should not be directly coupled to the Via runtime. I can totally see your broadcastable state store be a dependency injected into a via page init func. e.g.