 | Support/Help | 435 Members |
| 3 Servers |
| Support/Help | 435 Members |
| 3 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Sep 2022 | ||
 WorldSEnder#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 |
| WorldSEnder#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 |
 Meerkat | 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 |
| Meerkat | I ask this question never having used yew, and have barely even started tutorials for rust in general. | 20:46:03 |
| WorldSEnder#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 |
| Meerkat | 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 |
| WorldSEnder#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 |
| WorldSEnder#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 |
 Christopher 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 | ||
| Christopher 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 |
| WorldSEnder#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 |
| WorldSEnder#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 |
 koji | Thank you! I missunderstood a lot maybe... I must read These Pages. | 07:54:56 |
| Christopher 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 |
| WorldSEnder#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 |
 Revnixcad joined the room. | 18:06:41 | |
| Revnixcad | 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 | ||
| Christopher 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 |
 void22 joined the room. | 04:52:03 | |
 Amogus joined the room. | 05:54:38 | |
| Amogus | hi | 05:54:41 |
| Amogus | | 05:54:55 |
| Amogus |  Download unknown.png | 05:55:39 |
| Amogus | but is not working | 05:55:44 |
| Amogus | nevermind | 05:59:56 |
| Amogus | is ok now | 06:00:00 |
 sjud | How do you click html buttons generated by html!() in tests #[wasm_bindgen_test] ? | 12:24:34 |
| sjud | 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 |
 Voidpumpkin#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 |
| sjud | hmm thanks! I've never heard of that. I'll check it out 🙂 | 23:32:14 |