anp / moxie Goto Github PK
View Code? Open in Web Editor NEWlightweight platform-agnostic tools for declarative UI
Home Page: https://moxie.rs
License: Apache License 2.0
lightweight platform-agnostic tools for declarative UI
Home Page: https://moxie.rs
License: Apache License 2.0
Dependabot can't resolve your Rust dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
info: syncing channel updates for 'nightly-2019-08-12-x86_64-unknown-linux-gnu'
info: latest update on 2019-08-12, rust version 1.38.0-nightly (00ee1b47f 2019-08-11)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
Updating crates.io index
error: no matching package named `topo` found
location searched: /home/dependabot/dependabot-updater/dependabot_tmp_dir/topo
prerelease package needs to be specified explicitly
topo = { version = "0.8.2-pre" }
required by package `moxie v0.1.1-alpha.1-pre (/home/dependabot/dependabot-updater/dependabot_tmp_dir
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
You can mention @dependabot in the comments below to contact the Dependabot team.
Requires being able to update the toolchain past rust-lang/rust#61872.
Currently all arguments have to be passed via the illicit env, which has the downside of having to be 'static and needing to use interior mutability.
I want to propose a more explicitly defined interface that the mox macro
consumes. Some of this is based on my own local fork I'm using for
moxie-native.
Everything I'm talking about here is based on my own requirements for
moxie-native, and I'd like to know if any of these requirements are too
strict for other implementations, or if there are other ways of
improving this.
I'll start off with suggesting that as much as possible be moved into a
module named mox_impl
, so that we don't pollute the namespace of
programs and require a blob import like use moxie_native::prelude::*;
.
Inside of this module, there will be another namespace for host elements
(which we will distinguish from user components, as I'll detail below).
There will also be one for attribute names, and for event names.
None of the types used here are literal, but are just to name the return
values so you can match them up to where they get plumbed into.
mod mox_impl {
mod elements {
// Note that this is not a macro.
fn element_name_here(
with_builder: impl FnOnce(builder: Builder) -> Builder
) -> Node;
}
mod attributes {
fn attr_name_here() -> Attribute;
}
mod events {
fn on_event_name_here() -> Event;
}
}
The builder API has these methods on it (again, the types are not actual types):
trait Builder {
fn set_attr(self, key: Attribute, value: Attribute::Value) -> Self;
fn on_event(self, event: Event, callback: impl FnMut(event)) -> Self;
fn set_data(self, key: &'static str, value: DataValue) -> Self;
fn add_child(self, child: Node) -> Self;
fn enter_fragment(self, with_builder: impl FnOnce(builder: Self) -> Self) -> Self;
}
<element _=(...)>
syntax. Zero argument components need to be written<element />
though. <element _=() />
would work<element on={func} />
, events actually have names, so<element on_foo={func} />
turns into.on(mox_impl::events::on_foo(), func)
.<element data_foo=4 />
-> .data("foo", 4)
Implementation here is pretty straightforward, the biggest unknown is if
this new scheme will be difficult for other users of mox.
Simple implementations can define attribute functions as just a function
that returns a string, but this might be more manual than desired for
something like moxie-dom.
Some implementation hints from moxie-native that can come in handy here:
Builder<T>
set_attr
can be implemented using a trait like this:
trait HasAttribute<Attr> where Attr: Attribute {
fn set_attribute(&mut self, value: Attr::Value);
}
on_event
can be implemented the same way using a HasEvent
trait.enter_fragment
method are both good<foo some_attr=4 />
mox_impl::elements::foo(|builder| {
builder
.set_attr(mox_impl::attributes::some_attr(), 4)
})
<bar>
<user_component _=(1, "foo") />
</bar>
mox_impl::elements::bar(|builder| {
builder
.add_child(user_component!(1, "foo"))
})
<button on_click={func} data_foo=4 />
mox_impl::elements::button(|builder| {
builder
.on_event(mox_impl::events::on_click(), func)
.data("foo", 4)
})
<foo>
<bar />
"text"
{children}
</foo>
mox_impl::elements::foo(|builder| {
builder
.add_child(mox_impl::elements::bar(|builder| builder))
.add_child("text")
.add_child(children)
})
<foo>
<>
<fragment_child />
<>
</foo>
mox_impl::elements::foo(|builder| {
builder
.enter_fragment(|builder| {
builder
.add_child(mox_impl::elements::fragment_child(|builder| builder))
})
})
Behavior here isn't super clear, but adding a create_fragment
function
to mox_impl
to handle this case seems flexible enough.
<>
<fragment_child />
</>
mox_impl::create_fragment(|builder|
builder
.add_child(mox_impl::elements::fragment_child(|builder| builder))
)
This one is tricky to support, and I currently can't handle it correctly
in moxie-native without trait specialization. I haven't thought of any
workarounds that don't require modifying the syntax to be like
..{iterator}
or something like that. Any ideas here would be nice.
<foo>
{[1, 2, 3].iter().map(|index| mox!(
<number value={index} />
))}
</foo>
mox_impl::elements::foo(|builder| {
builder
.add_child(
[1, 2, 3].iter().map(|index|
mox_impl::elements::number(|builder| {
builder
.set_attr(mox_impl::attributes::value(), index)
})
)
)
})
Dependabot can't resolve your Rust dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
This project is part of a Rust workspace but is not the workspace root.Please update your settings so Dependabot points at the workspace root instead of /dom/examples/todo.
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
You can mention @dependabot in the comments below to contact the Dependabot team.
Should be fixed in the 1.38 release.
Right now the mox docs are in the moxie crate, which means that they can't use the dom definitions to demonstrate and test the mox macro.
Would be useful to define some test/docs-only builders in the core moxie crate that can be used in cases like this.
as_
, to_
, into_
conventions (C-CONV)iter
, iter_mut
, into_iter
(C-ITER)Copy
, Clone
, Eq
, PartialEq
, Ord
, PartialOrd
, Hash
, Debug
,Display
, Default
From
, AsRef
, AsMut
(C-CONV-TRAITS)FromIterator
and Extend
(C-COLLECT)Serialize
, Deserialize
(C-SERDE)Send
and Sync
where possible (C-SEND-SYNC)Hex
, Octal
, Binary
formatting (C-NUM-FMT)R: Read
and W: Write
by value (C-RW-VALUE)?
, not try!
, not unwrap
(C-QUESTION-MARK)Deref
and DerefMut
(C-DEREF)bool
or Option
(C-CUSTOM-TYPE)bitflags
, not enums (C-BITFLAG)Debug
(C-DEBUG)Debug
representation is never empty (C-DEBUG-NONEMPTY)This and associated helpers a la https://testing-library.com/docs/dom-testing-library would be useful for testing.
#[illicit::from_env(foo: Option<&Foo>)]
should work.
$CRATE-0.1.0
or somesuch seems good.
It should probably be an expression like #[topo::nested(slot = Ev::NAME)]
.
The division is pretty easily visible in the children vs. attribute methods.
Tried to update two state variables on the same button press:
let total = state!(|| 10);
let current = state!(|| 10);
element!("button", |e| e
.attr("type", "button")
.on(|_: ClickEvent, _| Some(0), current)
.on(|_: ClickEvent, _| Some(0), total)
.inner(|| text!("Reset")));
Seems like only the first one is getting updated (I even swapped the order and tried again to double check haha).
URL apis: ???
srcsets?
Enums:
coords
crossorigin
attributetrack::kind
img::{decoding, loading}
preload
target
What's working on my Windows machine right now:
-Zprofile
run as suggested on the grcov readme, and from cargo cov test
output)I have a codecov token, but am going to defer tying all of this together with a CI config until after publishing some releases.
It would be nice to have a ready-made breakdown of where build time is being spent in the dependency graph.
Right now memoization always needs to receive an owned argument, even if the argument hasn't changed. This results in a number of inefficiencies, like cloning strings on every revision just so they can be compared to the previous revision's and then discarded when they're in fact equal.
I think the API probably looks something a bit like this:
memo_ref<Ref, Arg, Output>(reference: Ref, init: impl FnOnce(Arg) -> Output)
where Ref: ToOwned<Owned=Arg> + PartialEq, ...
Dependabot can't resolve your Rust dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
This project is part of a Rust workspace but is not the workspace root.Please update your settings so Dependabot points at the workspace root instead of /dom.
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
You can mention @dependabot in the comments below to contact the Dependabot team.
The contributing document or the project book should explain the different types of tests and how to contribute to them.
Moxie is looking very promising.
I often (and concretely for something I'm working on) need something similar to Reacts useEffect
and dom references to interact with dom nodes like <video>
, <audio>
, ...
I assume this is not yet implemented?
Would be highly appreciated.
If you give some pointers on where to start I could maybe find the time to work on this myself.
Right now it looks like we'll need to block all stateful operations every frame to let the state store settle down and generate a consistent view of the world.
I suspect we'll want to support concurrent writers & readers who "care about" different frames. A single state store should be able to support running composition for frame N, layout for the previous frame, etc, just like a database.
As we move towards having "properly" typed support for all elements we can also offer an extension API to recover the typed wrappers from augdom. For example, instead of having access to only the raw node of a button, a moxie_dom::elements::forms::Button
could also have an API to return a web_sys::Button
.
I've come across a situation where dynamically generated strings are not rendered .
I'm not sure if I misunderstand how conditional rendering is supposed to work, or this is an issue with the xml macro.
The rendered content correctly switches from Loading
to "Loaded", but the {count}
is not displayed. The <span />
is inserted into the dom, but is empty.
#[topo::nested]
#[illicit::from_env(state: &Key<State>)]
pub fn list() {
moxie::once!{
|| {
log::info!("LOADING");
// ... send fetch request
}
};
if state.loading {
mox!( <p> "Loading..." </p> );
} else if let Some(err) = &state.error {
mox!( <p> {format!("Error: {}", err)} </p> );
} else {
let items = &state.data.items;
let count = items.len().to_string();
mox!(
<p class="x">
"Loaded"
<span>{count}</span>
</p>
);
}
}
Hello, I was interested in your project and I was wondering how do I get the cargo tools used in the README? It would be helpful if their was an installation step in the README.md
Dependabot can't resolve your Rust dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
This project is part of a Rust workspace but is not the workspace root.Please update your settings so Dependabot points at the workspace root instead of /dom/examples/hacking.
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
You can mention @dependabot in the comments below to contact the Dependabot team.
Dependabot can't resolve your Rust dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
This project is part of a Rust workspace but is not the workspace root.Please update your settings so Dependabot points at the workspace root instead of /dom/examples/hacking.
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
You can mention @dependabot in the comments below to contact the Dependabot team.
To get the repository tooling set up:
if you are on Ubuntu you will need to make sure
libssl-dev
package is installed, not sure what the ssl development package would be named on other distributions.
Originally posted by @Garett-McCarty in #34 (comment)
Further to discussions on Discord. With caller tracking being possibly implemented in rustc it is important to understand what this means for spawned threads and parallelism in general.
In the below by execution context I mean the environment associated with the callsite generated by either topos::root! , topos::call! or [topos::nested]. This includes the topos::current() Id.
Questions include:
For instance thread with Id:4 spawns a thread, should that new thread have any particularly Id.
For instance thread with Id:4 spawns a thread, if it has also by default has Id:4 can there be any guarantee that the id of the first new callsite in that thread would be invariant over consecutive thread spawns.
Should there be explicit control over the above behaviour and execution context via some kind of spawn threading api.
if a thread is spawned and then executes a loop which in turn executes several call-site tracked methods (with a revisit to each call-site intended). How does one ensure that this happens. Would a topo::root! be sufficient to guarantee this.
I.e. will the below be sufficent to ensure that a and b always refer to the same Id.
thread::spawn(move || {
for i in 0..10 {
topo::root!(
topo::call!( let a = topo::current() );
topo::call!( let b = topo::current() );
)
}
});
This project is written in Rust, but readme says "go". Please, fix it.
This should be like the existing produce
macro(s), but separating the memoization from the mounting/unmounting. I'm not sure that it's necessary for moxie to have a notion of parent nodes in the core runtime -- relating those is complex and perhaps topo env + memoization is the right level of abstraction?
We already have a bunch of HTML shenanigans happening in-tree, it would be great to inject the script tag when running from the project server instead of having to manually include it.
Dependabot can't resolve your Rust dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
This project is part of a Rust workspace but is not the workspace root.Please update your settings so Dependabot points at the workspace root instead of /dom.
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
You can mention @dependabot in the comments below to contact the Dependabot team.
Currently the cargo published
command ensures that all workspace crates which are appropriately versioned have been published to crates.io. This uses an auth token for my crates.io account (attached to this github account) but this is at odds with goals of the project:
The most obvious short-term fix is to start publishing the current crates under an organizational account.
I think augdom is the only one right now.
Dependabot can't resolve your Rust dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
This project is part of a Rust workspace but is not the workspace root.Please update your settings so Dependabot points at the workspace root instead of /dom/examples/todo.
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
You can mention @dependabot in the comments below to contact the Dependabot team.
I stumbled on the following peculiar situation:
When not accessing a key injected via illicit::from-env
, building results in a ICE.
The ICE goes away when any access to the key occurs.
moxie: master
nightly: 2019-11-16
#[topo::nested]
#[illicit::from_env(state: &Key<State>)]
pub fn whatever() {
// UNcommenting this line removes the ICE
// let _ = state.field;
mox!( <p> "Loading..." </p> );
}
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: DistinctSources(DistinctSources { begin: (Real("src/lib.rs"), BytePos(0)), end: (Real("src/views/some_view.rs"), BytePos(1831)) })', src/libcore/result.rs:1187:5
stack backtrace:
Boolean attributes should create dom nodes that either include the key or exclude it rather than always including it and setting to the Boolean value. For example, try using disabled on buttons.
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.