emmanuelantony2000 / valerie Goto Github PK
View Code? Open in Web Editor NEWRust front-end framework for building web apps
License: Apache License 2.0
Rust front-end framework for building web apps
License: Apache License 2.0
The router works like an a singleton of an enum that represents the route options.
When the onpopstate
event is received, a component local state (eg. Atomic*
) will be set to the new route.
This requires that the state objects need to be able to replace themselves with an entirely new component, with their own children and channels.
enum Routes {
Login,
Home,
Post(PostID),
}
impl Default for Routes {
fn default() -> Self {
Self::Login
}
}
impl From<Url> for Routes {
fn from(self) -> Routes {
// ...
}
}
fn router() -> Node {
use Routes::*;
let router = StateMutex<Routes>::new();
HistoryService::route(router); // set up async monitor of the history API, convert url to Routes and send changes to `router`
div!(
router.formatter(|r| {
match r {
Login => login(),
Home => home(),
Post(id) => post(id),
}
}
).into()
}
What this requires is that StateMutex can take a closure returning a node which can replace the existing node.
Is this already in place, but I don't understand how to do this? or does it require an enhancement?
Any thoughts?
Issue created to brainstorm on this topic.
An initial idea is to bring States to attributes and CSS probably with functions, bind_attr
and bind_css
. I need some opinions.
Just curious about SSR and where Valerie stands on it. I imagine it's not possible now, but would it require massive changes to make it possible? Would work towards SSR be in line with the project goals?
Is JavaScript interoperability a goal?
I personally don't think it is needed and shouldn't be added if it would add complexity to the framework.
Anyway I think it would be important to have this (JavaScript interop as a goal, or not, and the reasons why) stated in the readme.
Describe the bug
I was running the input_state example , but it's not showing the value in browser when I type in text box. ( attached screenshot)
To Reproduce
Steps to reproduce the behavior:
run miniserve and go to http://127.0.0.1:8080/static/index.html
type the text box with some characters.
Currently state bindings to nodes are permanent, meaning that even if the node is removed from the DOM (user navigated to a different route, deleted the list item, closed the dialog, etc) it will still stay in memory and will still be updated whenever its state dependencies are updated. Naturally in some cases this could lead to excessive memory usage and slow page performance.
Here's my thinking on this issue, based on past experiences. Feel free to go a different way if you prefer.
Depending on the intended browser support, this might be a great use case for the new-ish MutationObserver API, which will execute a callback function whenever an element is removed from the DOM. I have heard of performance issues with this API in the past but they've hopefully gotten ironed out by now. If it's still too heavy, Valerie itself could track when State-bound elements are removed by the library itself, although this could lead to hard-to-find memory leaks when users circumvent Valerie and modify the DOM directly in their code.
The second issue is how to actually remove the state listeners. JS has no way of cancelling an await
-- once a Promise is awaited, the calling async
function will remain in memory (and take some CPU cycles) until that Promise gets resolved. So, this approach would work but have a potential memory and performance cost:
let mut old = StateId::new();
while let Some((new, value)) = stateRx.receive(old).await {
if (element_was_removed(elem)) {
break;
}
// ... perform element update ...
old = new;
}
A safer solution would use a second channel that emits when the element is removed. Something like:
let mut old = StateId::new();
while true {
let next_event = future::select(stateRx.receive(old), destroyedRx.receive(old)).await;
match next_event {
Either::Left((x, b)) =>{
// ... perform element update ...
old = new;
},
Either::Right((y, a)) => break,
}
}
This will run the next loop iteration when either a) the state is updated or b) the element is removed. In practice I don't know if this actually ends up being more performant. It is safer in that elements that have been removed will no longer take up any resources, but heavier in that all state listeners must now listen to two different Futures.
Lastly there's the issue of where to store extra data about Nodes, in this case the destroyed state for each one (destroyedRx
in the example above, or whatever boolean drives element_was_removed
above that). As far as I can tell JsValues cannot be used as the key for a Set or HashMap, so I don't know how well a global datastore inside Valerie would work. That leaves storing the data in the DOM tree itself as the best option, either as HTML attributes or just as additional JS properties tacked on to the Node object. Both have pros and cons, and both specifically have the con that the stored values must all be JS-safe, eg. a Promise instead of a Future. There might be a hybrid approach that works, like storing an index somewhere on the JS object and then using that index as the key to a global datastore inside Rust. Honestly I have no idea which one would perform the best, I have a lot of JS development under my belt but I'm still fairly new to Rust (hopefully that isn't too obvious :) )
Should we bring stpl to Valerie?
https://docs.rs/stpl/0.5.0/stpl/
Because as valerie
progresses we might have templates and UI component libraries. Macros might not be a good solution when there are two buttons one a normal button!
and one maybe a material button!
, because of the global scope of macros.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.