nerdblood

This is a great answer, thanks. I'll have to look more into conditional compilation. That's new to me.

Nothing I guess. I just was thinking there would be more to it than that.

Thanks, yeah it felt like too many tests to keep in file. I can live with that directory approach. TY!

Error handling was kind of a pain to wrap my head around within the Rust Ecosystem, between the different crates, custom enums and learning about Box. I do enjoy errors now that I understand how the community is using them a little better, and the idea of there being one control flow with errors being a possible 'result'.

Author seems to have some good experience composing errors in Rust applications... good read!

This is cool. I'm a front-end focused dev by trade and have been 11 years now. I've been picking up Rust as a side hobbie for 6 months or so and have not even peaked at these front-end frameworks. I know Lemmy is all about Rust, but I still think it's pretty cheeky they're using Rust for the front-end.

About Leptos specifically... If there's no shadow dom / rerenders and not trying to be react, I already like it better than it's competitor.

I'd provide more code but it's a mess and full of old commented-out code. Your examples are perfect! combining the DB fields into it's own struct is something I hadn't thought of... and I totally get why having a bunch of options sitting in the Army struct would be problematic. I'm really excited about rust for moving these sorts of errors to compile time.

The INTO example seems great too. I'm ok with the performance hit of cloning for now... lifetimes and pointers feel like a tier above where am at with my rust skills, and I'll circle back to get a better handle on them later.

One question about the INTO example... I always hear it's better to just implement FROM and get INTO for free. Does that not make sense for my use case? If I did it, would it look something like:

impl From<ArmyWithDbProps> for Army { fn from(self) -> ArmyWithDbProps { self.armyWithDbProps } }

If you absolutely can’t make it work, a single Option at least would be more correct as all the fields on the inner struct would be optional together.

Wait really? If I wrap a struct in Option it makes all the fields optional?

Good to know that you think the Into approach seems better. Part of the purpose of this thread is to just gauge what's the better way to do this in Rust. Do you know what "separating the types with Into" would look like?

It was basically me passing BaseArmy in as a param to a fucntion, then returning an Army type. I tried a few different things, but what I really wanted to do was just spread out the struct like I would in Typescript. Rust seems to support this UNLESS there's one field that's different.

Let me give builder pattern a try. I was literally just learning more about it, but didn't think to apply it here.

EDIT:

Here's what' I'm trying to do: Battalion { count: count, position, ..db_battalion_template }

Then the error I get:

mismatched types expected Battalion, found BattalionTemplate

EDIT2:

After more fiddling around and adding the from conversion:

Battalion { count: count, position, ..Battalion::from(db_battalion_template) } impl From<BattalionTemplate> for Battalion { fn from(a: BattalionTemplate) -> Self { let serialized = serde_json::to_string(&a).unwrap(); Self { position: 0, ..serde_json::from_str(&serialized).unwrap() } } }

I get this error: thread 'main' panicked at 'called Result::unwrap() on an Err value: Error("missing field position", line: 1, column: 227)'

Edit 3:

I at least got the from conversion to work by just manually specifying the Battalion fields. Should I just accept that I can't spread struct properties from one type on to another unless they have exactly the same fields?

This is fantastic, thanks for sharing!

I might not need global state, the more I think about it. I'll start with passing a struct and see where that gets me, thanks!

Yeah I tried out lazy_static, but the compiler was strongly urging me not to use it since it's being deprecated. Thanks, I didn't know about OneCell.

Eh , its probably just temporary. People just had apps they've used for 10 years yanked away and it's jaring how it all went down. Of course people are going to want to talk about it.