databasedav

Results 76 comments of databasedav

~~[Silkenweb](https://github.com/silkenweb/silkenweb) has an interesting approach to this [`RefSignalOrValue`](https://github.com/silkenweb/silkenweb/blob/53296065ac6ac4c65f7af9ce4396f076ced56cc8/packages/signals-ext/src/value.rs#L57) though i'm not sure if it~~ > ~~makes the types too complex for both compiler and human~~ edit: nvm, `RefSignalOrValue` has nothing...

just noticed there's already a `Task::start_blocking` that the other api's delegate to, we could call this new function [`spawn_blocking`](https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.html) or [`to_thread`](https://docs.python.org/3/library/asyncio-task.html#asyncio.to_thread) instead

> There is one bigger problem with Task::start_blocking - you can't use Mutables inside it that come from the main thread. It means basically all Mutables you would like to...

it's the same convenience that one gets from the `map_bool_signal` family of functions, it's true that one can always just do a `.map_some(|_| signal()).flatten()`, but this is also the case...

the entire motivation is that `contenteditable` allows non-text elements to be treated like text inline in a text box, so anything from an image to a custom data selector of...

right, I was suggesting the latter, i.e. `TextArea` -> a `div` with `contenteditable`, in order to enable the benefits highlighted in my above comment

yes this is close, i want this exposed as a configuration option to `mzoon build`, i'll try to open a pr for it

@MartinKavik actually i don't think i can do this alone, how would i add a new env var for `mzoon build` `NOINDEX=1` and thread it through to `index_by_robots`? an env...

i've created an example of what i mean by "unexpected" here https://github.com/databasedav/MoonZoon/blob/layer_ergonomics_example/examples/start_with_app/frontend/src/main.rs; relevant snippet: ```rust const LAYER_INDEX_MASTER_ORDERING: &[&str] = &[ "dropdown", "attachment", ]; fn get_layer_index(name: &str) -> i32 { LayerIndex::MAX_VALUE...

i think idea 2 is going in the best direction, the nearby element's container should ideally have no effect on the element, anything that happens to the nearby element should...