!LtIECwsjkkjinzHTTB:matrix.org

Support/Help

435 Members
3 Servers

Load older messages


SenderMessageTime
23 Sep 2022
@_discord_120619855056601088:t2bot.ioWorldSEnder#8649 I suppose you can somewhat hack around it with noderefs and manually calling https://docs.rs/web-sys/latest/web_sys/struct.HtmlSelectElement.html#method.set_selected_index in rendered/use_effect. But it's not as declarative as it "should" be 19:49:48
@_discord_120619855056601088:t2bot.ioWorldSEnder#8649 iirc, "selected" is not special case though, like "value" is and there is no special handling for it in 0.19 19:50:46
@_discord_338062815585894412:t2bot.ioMeerkat Is Yew purely frontend? Can I use this is combination with a rust backend such as rocket, similar to how NextJS handles both frontend and backend in a single process / codebase? 20:45:33
@_discord_338062815585894412:t2bot.ioMeerkat I ask this question never having used yew, and have barely even started tutorials for rust in general. 20:46:03
@_discord_120619855056601088:t2bot.ioWorldSEnder#8649 there is a server-side render mode, but no persistent session or live streaming of the interface happening. So I'd say more or less frontend yes 20:47:34
@_discord_338062815585894412:t2bot.ioMeerkat Hmm, less about server rendering and more about the UI fetching data from the backend via some JSON api. But rather than having a Rocket backend server codebase and a separate repo for a Yew frontend, can I put them in a single codebase to share data-structures? 20:53:29
@_discord_120619855056601088:t2bot.ioWorldSEnder#8649 sharing datastructure is of course possible. But keep in mind that in general frontend and backand are compiled to different targets (wasm-unknown-* vs e.g. linux-*) so while a common dependency is possible, sharing the compiled binary is often not what's happening 20:59:38
@_discord_120619855056601088:t2bot.ioWorldSEnder#8649 but yes, you can write in a style where you share code between backend and frontend if you're careful. There's some guardrails missing to have all that checked at compile time, e.g. wasm-bindgen panics at runtime when the bound functions are called outside a wasm target, but you can share code 21:01:18
@_discord_775145661103603735:t2bot.ioChristopher Hunt#2382 So setting the value attribute of select should work for 0.19? And is the way forward here to use the bindings approach you cited for beyond 0.19? 22:43:36
24 Sep 2022
@_discord_775145661103603735:t2bot.ioChristopher Hunt#2382 An update: I've gone with using the rendered method to update the select elements via noderefs. This feels like an unfortunate gap in Yew. It'd be great to understand the strategy going forward i.e. whether bindings are to be used for all attributes that can vary. Thanks. 02:09:17
@_discord_120619855056601088:t2bot.ioWorldSEnder#8649 well the technicality to understand is that there is a small mismatch between common user-expectation and attributes on html elements. Let me review: There are a bunch of attributes, such as selected on <option> that, when normal html is parsed, only influence the default, i.e. the state when the element is initially loaded.

When you update the attribute on the html element (e.g. by "Inspect Element" and manually type a new value in the browsertools), this does not influence the state (since the element is already loaded, the default is already applied to the actual state. The element existing in the page is a HtmlOptionElement in this case, and the attribute is reflected in the property HtmlOptionElement.defaultSelected (meaning this one gets updated when you update the attribute and vice-versa. But changing the attribute does not change the HtmlOptionElement.selected property (yes naming is overloaded between attribute and property. This only adds to the confusion), which is the actual state of the element you see on the page.

Now, what is uncontroversial is that the PR allows you to, in a declarative way, influence properties on a *Element instead of, as prior to the PR, changing an attribute, which indirectly changes its reflecting property.
Alas, the more controversial part, and the root for user confusion, is that there is already a hack in place. Specifically, for some properties, such as the value attribute on a HtmlInput - which would suffer a similar problem, its reflected by the defaultValue property - the hack automatically assumes that the user meant to set the property and accordingly do that instead, causing the expected update of the input text. But this is a manually maintained list of properties and has been kinda sloppily maintained.
Tl;dr of this wall of text: you should now be able to work-around an attribute missing from the list of special cases, although this list should also be updated at some point.
03:05:40
@_discord_120619855056601088:t2bot.ioWorldSEnder#8649 Btw, you might think that only using the property is a good idea, but this having the attribute facilitates SSR, since the "the default state on first load" is exactly what you're targeting there 03:11:47
@_discord_529122432800260096:t2bot.iokoji Thank you!
I missunderstood a lot maybe...
I must read These Pages.
07:54:56
@_discord_775145661103603735:t2bot.ioChristopher Hunt#2382 Wow. Thanks for the detailed reply. I’ll have to digest it further, but TL;DR, HTML wasn’t designed for SPAs. 😉 07:57:34
@_discord_120619855056601088:t2bot.ioWorldSEnder#8649 the browser can be very protective about what kind of data it reveals to scripting environments in "third-party" content. Understanding all the rules takes so much time. But at least, nowadays, the default seems that something is inaccessible, so there's less inadvertent leaking of data - but more to do when you do actually want to share stuff with your frotnend 😄 14:48:29
@_discord_684894673005051935:t2bot.ioRevnixcad joined the room.18:06:41
@_discord_684894673005051935:t2bot.ioRevnixcad Starting my first project with yew, is there any example available based on Brad Frost’s Atomic Design principle. Just want to make a basic portfolio webpage. 18:06:43
25 Sep 2022
@_discord_775145661103603735:t2bot.ioChristopher Hunt#2382 Thanks again for the replies. TBH in all my years of HTML I’ve never appreciated the difference between attributes and properties. Perhaps I should have, but I’ll bet there are many more like me, perhaps even the majority of frontend devs.

To me, the html! macro is about manipulating the dom, hence virtual dom etc. I think we need to eliminate the confusion between attributes and properties, perhaps having both an html! macro without properties, and a dom! macro that favours properties and supports attributes with the ~ syntax. I’ve continued the conversation here: https://github.com/yewstack/yew/pull/2819#issuecomment-1257076557.
01:43:38
@_discord_387156607059886083:t2bot.iovoid22 joined the room.04:52:03
@_discord_873233102548377600:t2bot.ioAmogus joined the room.05:54:38
@_discord_873233102548377600:t2bot.ioAmogus hi 05:54:41
@_discord_873233102548377600:t2bot.ioAmogus
<h1> {"For some reason, my cat is" <i>{"weird"}</i>} </h1> 
05:54:55
@_discord_873233102548377600:t2bot.ioAmogusunknown.png
Download unknown.png
05:55:39
@_discord_873233102548377600:t2bot.ioAmogus but is not working 05:55:44
@_discord_873233102548377600:t2bot.ioAmogus nevermind 05:59:56
@_discord_873233102548377600:t2bot.ioAmogus is ok now 06:00:00
@_discord_824336128840695888:t2bot.iosjud How do you click html buttons generated by html!() in tests #[wasm_bindgen_test] ? 12:24:34
@_discord_824336128840695888:t2bot.iosjud Or I guess the better question is how to interact with the DOM in test? Setting field values, clicking submit buttons etc. 12:28:03
@_discord_134721610165780481:t2bot.ioVoidpumpkin#8396 sjud easiest approach to test yew apps is to make some ui tests with something like cypress, or more rust approach - thirtyfour crate. 19:16:42
@_discord_824336128840695888:t2bot.iosjud hmm thanks! I've never heard of that. I'll check it out 🙂 23:32:14

There are no newer messages yet.


Back to Room List