HtmlTextAreaElement and mogwai 0.5.0

[paulalesius]

Hi, is it possible to send content to a element somehow?</p> <p>The <textarea> element requires a call to HtmlTextAreaElement::value() attribute but I haven't found a way to do this from the view or logic code.</p> <p>I can't find a way to cast an element inside a builder! {} ViewBuilder to HtmlTextAreaElement to call the value() method, and I can't seem to send messages to it in any way that calls the value() method.</p> <p>Note this is not the <textarea value= /> attribute, which you can send messages to fine, but it's a method in javascript on the element.</p> <p>Some help with how to do this would be highly appreciated!</p> <p>Thank you! </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/paulalesius"><img src="https://avatars.githubusercontent.com/u/6217472?v=4" />paulalesius</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>So far, I've managed to acquire a HtmlTextAreaElement from post:build:</p> <pre><code class="language-rust"><textarea post:build=move |dom: &mut Dom| { match dom.inner_read() { Either::Left(rwguard) => { let area = rwguard.clone().dyn_into::<HtmlTextAreaElement>(); loop { rxv.clone() // ?? } } Either::Right(ssr) = {} } }></code></pre> <p>But I can't find a way to poll a stream from there. And that's a read-write guard that I don't think that one should be holding on to indefinitely in a loop anyway.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/schell"><img src="https://avatars.githubusercontent.com/u/24942?v=4" />schell</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>The way that I've been dealing with this is to use the <code>post:build</code> operation to send a clone of the <code>Dom</code> to my logic loop. That way I can hold on to the <code>Dom</code> (which has a clone of the <code>HtmlTextAreaElement</code> if compiled for wasm) for as long as I need: </p> <pre><code class="language-rust">fn view(tx: Sender<Dom>) -> ViewBuilder<Dom> { builder! { <textarea post:build=move |dom: &mut Dom| { tx.try_send(dom.clone()).unwrap(); }></textarea> } } async fn logic(mut rx: Receiver<Dom>) { let text_area_dom = rx.next().await.unwrap(); { if let Some(text_area) = text_area_dom.clone_as::<HtmlTextAreaElement>() { // ... do `web_sys` stuff with text_area } } loop { // ... loop as normal } }</code></pre> <p>There's an <a href="https://zyghost.com/guides/mogwai-cookbook/view_capture.html">entry in the mogwai cookbook about capturing parts of the view</a> that may help. There are also a few examples of this in the examples dir. </p> <p>Let me know what you think :) </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/paulalesius"><img src="https://avatars.githubusercontent.com/u/6217472?v=4" />paulalesius</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Was using a ::broadcast channel to send things to the logic, and a ::mpmc to send things to the view, after the examples in the cookbook.</p> <p>Your example uses tx.try_send() from a ::mpmc channel.</p> <p>So in the logic</p> <pre><code class="language-rust">183 | let mut sources = mogwai::futures::stream::select_all(vec![rx_broadcast.boxed(), rx_mpmc.boxed()]); | ^^^^^ `*mut u8` cannot be shared between threads safely</code></pre> <p>So I'm trying to refactor the component architecture I'm trying to establish, to only use ::mpmc to send things to the logic.</p> <p>It's very tricky to figure out an architecture that is consistent to focus on the business logic.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/paulalesius"><img src="https://avatars.githubusercontent.com/u/6217472?v=4" />paulalesius</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>I don't think it makes sense for everything to be asynchronous. The complexities involved in performing basic logic will have one fiddling with channels for days, and we haven't even begun on the business logic of the application.</p> <p>Asynchronous programming should be a tool that you use to achieve something, instead of for interacting with the API which serves no purpose from what I can tell, but to prevent one from programming.</p> <p>Given the asynchronous nature of 0.5.0 it looks like we should only use ::broadcast channels exclusively, so that we don't run into issues later.</p> <p>But now I can't send a mogwai::prelude::Dom through a ::broadcast channel in WASM because its wasm_bindgen::JsValue isn't std::marker::Send.</p> <p>I'm going back to refactoring again using ::mpmc channels, but the logic already has a loop reading ::broadcast messages, and blocking on .await. Where do you handle the ::mpmc messages?</p> <pre><code class="language-rust">let mut sources = mogwai::futures::stream::select_all(vec![rxl.boxed()]); loop { match sources.next().await { } }</code></pre> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/schell"><img src="https://avatars.githubusercontent.com/u/24942?v=4" />schell</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Hopefully I can address all your concerns.</p> <blockquote> <p>It's very tricky to figure out an architecture that is consistent to focus on the business logic.</p> </blockquote> <p>This can be true. Even if you're used to working with the various channels it's easy to get confused. This is something I'll be working on in the future. It would be easier if channel implementations' <code>Sender</code> was <code>Sink</code> as well as their <code>Receiver</code> being <code>Stream</code>, but most <code>Sender</code>s are not <code>Sink</code>. </p> <blockquote> <p>I don't think it makes sense for everything to be asynchronous.</p> </blockquote> <p>I agree, though I think the logic loops should be asynchronous because you often have to <code>await</code> things like requests or delays, etc. It's much less error prone to <code>await</code> the changes you expect than it is to <code>send_async</code> back into the logic loop and pick stuff back up at a later point, which is what <code>mogwai < 0.5</code> did.</p> <blockquote> <p>Given the asynchronous nature of 0.5.0 it looks like we should only use ::broadcast channels exclusively, so that we don't run into issues later.</p> </blockquote> <p>This is mostly correct. If you don't have a specific reason <em>not to use a <code>broadcast</code></em>, then you probably should. It should be the channel you reach for first, because it guarantees that all downstream <code>Receivers</code> get a clone of the message. This is especially important when making <code>ViewBuilder</code>s because we often give the builder a stream in the form of<code>tx_view.clone().filter_map(...)</code> - and if there are more than one of those sites and you're using the <code>mpmc</code> channel <strong>they will receive messages in round robin</strong>. For this reason I'll probably remove the <code>mpmc</code> channel in favor of <code>futures::channel::mpsc</code> (which is <code>Sink</code>). </p> <blockquote> <p>But now I can't send a mogwai::prelude::Dom through a ::broadcast channel in WASM because its wasm_bindgen::JsValue isn't std::marker::Send.</p> </blockquote> <p>You are correct that <code>JsValue</code> is <code>!Send</code>, but <code>Dom</code> <em>is</em> <code>Sendable</code>, which means it is <code>Send</code> when the target is not <code>wasm32</code>. Mogwai goes to a lot of trouble to make sure that on WASM the constraints are relaxed so you can pass around <code>JsValue</code> inside a <code>Dom</code> regardless of what target you're compiling for.</p> <p>The reason to use <code>mpmc</code> instead of <code>broadcast</code> is because <code>ViewBuilder</code> is not <code>Clone</code>, which is a requirement for <code>broadcast</code>. You should be fine sending your <code>Dom</code> nodes through <code>broadcast</code> because clones are cheap. Then in your logic loop keep them as <code>Dom</code> until you need the underlying <code>JsCast</code> type (<code>HtmlElement</code>, etc) - at which point you can use <code>visit_as</code> or <code>clone_as</code>. Just make sure not to keep the <code>JsCast</code> type around across an <code>await</code> point or else your future will no longer be <code>Send</code>.</p> <p>Thanks for exposing the confusion in channels. I'll have to do something to fix that. I'll probably drop <code>async_channel</code> altogether (which is the <code>mpmc</code> channel) in favor of using <code>futures::mpsc</code>. </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/paulalesius"><img src="https://avatars.githubusercontent.com/u/6217472?v=4" />paulalesius</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>And with regards to send_async and safety, all of my code that interacts with javascript is kept in a separate mod, and that still requires:</p> <pre><code class="language-rust">wasm_bindgen_futures::spawn_local(async move { });</code></pre> <p>Because they use JsValue objects from Javascript that are not "Send", so you cannot JsFuture::from(promise_with_jsvalue_objects).await from mogwai with_logic() loop.</p> <p>So again all of my code is async everywhere for seemingly no purpose, but all interaction with javascript requires wasm_bindgen_futures::spawm_local.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/schell"><img src="https://avatars.githubusercontent.com/u/24942?v=4" />schell</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>I see the confusion. Currently each time you call <code>with_logic</code> the <code>Component</code> replaces its logic with the given future. So your first future is replaced with your second future and subsequently dropped, including <code>rxn</code>, closing the channel. </p> <p>It does make sense that you would think it <em>appends</em> the logic though, and the implementation <em>could</em> do that, if desired. I suppose that would be preferable to using types to ensure that this confusion never happens (which would mean <code>Component::with_logic</code> returns a new type that that does not have a <code>with_logic</code> method). I like that, actually - because then you can split the updates of different parts of the same view between separate futures using different messages as you've done here. I will probably change to this behavior as a result of this conversation.</p> <p>I understand your frustration with the new changes. Trying to anticipate some that frustration I included the <a href="https://docs.rs/mogwai/0.5.1/mogwai/component/trait.IsElmComponent.html">IsElmComponent</a> trait, which works almost exactly the same as <code>0.4</code>'s <code>Component</code> trait. I decided to move away from the Elm style composition because there are already good alternatives like <code>sauron</code> there. <code>mogwai</code> is geared a bit more towards flexibility and speed, I guess. But with <code>IsElmComponent</code> you get your cake and can eat most of it too.</p> <p>Given some more time I'd like to rewrite your example to help you out, but I won't be able to until tomorrow morning (NZ time).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/paulalesius"><img src="https://avatars.githubusercontent.com/u/6217472?v=4" />paulalesius</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Thank you, closing issue.</p> <p>I understand how to use it now, deleted my whining posts, my bad. Great framework! ♥️</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/schell"><img src="https://avatars.githubusercontent.com/u/24942?v=4" />schell</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Thanks for the issue - it has illuminated some of the areas of mogwai that I haven't thought enough about. 🙇 </p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>