You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I am not sure if this would be better suited as modifications to this library or something that got built on top of this library to force certain standards. Anyway, this is my idea:
One of the major advantages of Rust is its type safety over something like JavaScript. Thus, the conversion to and from JavaScript are likely to cause issues. With that in mind, the first thing that sticks out as likely to cause mistakes is this webview.eval(&format!("updateTicks({}, {})", counter, user_data)). It just looks like it is waiting for typos to happen and weird bugs. By using some sort of macro/derive, I feel like the rust function fn updateTicks(counter: u32, userdata: i32) could be generated. I get that if updateTick is called in only one place, it doesn't really matter, but as applications get bigger and you use updateTick in 5 different issues, this would defend against a lot of potential bugs, especially if updateTick is ever changed to accept another argument.
A second spot were I see major potential gains is in enforcing the use of serde for type safe commands back to rust. Basically taking what is done in todo.rs and standardizing it. This again avoids the user directly passing around strings and gives them a Rust struct instead. I feel like this would best match with typescript/purescript/elm on the frontend to standardize what JavaScript sends over, but that would likely still be up to user choice.
I know that your elm and purescript examples are self contained, but if they need access to native resources(file io for persistence, etc), then it would be import to set this up well in rust. Also, with the setup, I feel like it is easier to just let the JavaScript render/grab user input and have all the business logic in rust. I feel like this may kinda turn into building the elm architecture in rust built on top of web-view.
Any questions/thoughts/opinions? I am hoping this sounds like at least a useful idea.
The text was updated successfully, but these errors were encountered:
So I am not sure if this would be better suited as modifications to this library or something that got built on top of this library to force certain standards. Anyway, this is my idea:
One of the major advantages of Rust is its type safety over something like JavaScript. Thus, the conversion to and from JavaScript are likely to cause issues. With that in mind, the first thing that sticks out as likely to cause mistakes is this
webview.eval(&format!("updateTicks({}, {})", counter, user_data))
. It just looks like it is waiting for typos to happen and weird bugs. By using some sort of macro/derive, I feel like the rust functionfn updateTicks(counter: u32, userdata: i32)
could be generated. I get that ifupdateTick
is called in only one place, it doesn't really matter, but as applications get bigger and you useupdateTick
in 5 different issues, this would defend against a lot of potential bugs, especially ifupdateTick
is ever changed to accept another argument.A second spot were I see major potential gains is in enforcing the use of serde for type safe commands back to rust. Basically taking what is done in todo.rs and standardizing it. This again avoids the user directly passing around strings and gives them a Rust struct instead. I feel like this would best match with typescript/purescript/elm on the frontend to standardize what JavaScript sends over, but that would likely still be up to user choice.
I know that your elm and purescript examples are self contained, but if they need access to native resources(file io for persistence, etc), then it would be import to set this up well in rust. Also, with the setup, I feel like it is easier to just let the JavaScript render/grab user input and have all the business logic in rust. I feel like this may kinda turn into building the elm architecture in rust built on top of web-view.
Any questions/thoughts/opinions? I am hoping this sounds like at least a useful idea.
The text was updated successfully, but these errors were encountered: