Newb questions for first app

[yatesco]

Hi, So, I'm familiar with Rust, react, and signals (although only in theory, not practice), and I've gone through the Leptos manual a few times. I have a few questions which I'd really appreciate getting some answers to. These all seem fairly "middle of the road" to me, but I can't quite nail down the right approach/confirmation/prior art.

I'm hoping some brave souls will work their way through this wall of text and give me factual corrections but also feedback from their own experiences :-).

For context, this is a proof of concept and will work purely client side - there is no stateful server anywhere, other than to serve the web assets (e.g. python3 -m http.server). My motivation for Leptos is because our back end has already migrated from Clojure to Rust, and htmx and the http crate just aren't working out (too much interactivity on the UI). dioxus is the other strong candidate but I worry it is too churny at the moment. If neither of these then it would be rescript, only because I just can't face JS or TS.

Bootstrapping the project

https://book.leptos.dev/getting_started/index.html is sufficient for pure client side, right? I don't need cargo-leptos?

Builder API rather than view! macro

I'm intending on using the Builder API (https://book.leptos.dev/view/builder.html) just for subjective ergonomic reasons. I realise there is a potential minor performance cost, but that's only on the server, correct?

v0.6 or v0.7

I'm trying to make this as "easy" as possible so I figure I should stick with v0.6? Or would you recommend v0.7 (if it's right around the corner and pretty much API stable for example)?

Storybook

Is there a similar tool to storybook that works with Leptos/WASM? I couldn't find one. Has anyone got storybook working?

Normalising/Denormalising and "transient local"/global state

My mind likes redux (actually Clojure/reagent!): one normalised big blob of state with multiple cursors that denormalise. Whilst this is still possible (https://book.leptos.dev/15_global_state.html), it doesn't seem very idiomatic. However, in my case, there is a lot of data that is used in multiple places.

A small example, there are a list of Customers ({id: 123, name: "Bob" ...}) and a list of Orders ({id: 321, customer: 123 ....}). I need to render an Order, including the customer's name, on multiple pages. In fact, most pages don't have any local state at all, the majority is just rendering the same different in different ways (e.g. a bunch of Customer pages and a bunch of Order pages).

(In reality, the DB struct has about 40 top level structs, some of which are themselves quite nested, and some of those top level entities may be 10s of thousands).

Things I know I could do:

Prop drilling

I could just dribble the necessary data through the component hierarchy, and maybe this is fine. But, well, it's pretty naff.

let [db, _] = create_signal(BigDB::default());
...
  <Customers customers={db.customers}/>
  <Orders orders={db.orders}/>
...

I understand the ergonomic cost of prop drilling in react (API messiness), but it has many benefits, including stupidly simple, albeit verbose APIs which are a joy to test.

As well as making data available, the other big issue is that updating anywhere in the DB structure will cause effectively (almost) all created signals to be "activated" to see if there are any changes.

Nested signals

(https://book.leptos.dev/view/04b_iteration.html#option-2-nested-signals)
I could break the cascade of unnecessary work by using nested signals, but how do you know when you have added enough nested signals? Making root level entries in the db (e.g. Customers and Orders) are a no-brainer, but should I also make each order a nested signal?

Rust's strong typing will prevent me from "confusion" as to whether something is a signal or a (vanilla? What's the term?) "value", but this still feels "fiddly", and hard to reason objectively about where in the DB graph nested signals should live.

Context

(https://book.leptos.dev/view/08_parent_child.html#4-providing-a-context)
I realise that Contexts in Leptos aren't as expensive as they are in React (in which every descendant component of the Provider is sensitive to the data provided by the Provider), and these are indeed a neat way of avoiding prop drilling.

Summary

I think my answer is going to be a combination of Context, relatively coarse grained nested signals (e.g. just at the top level) and memo'd slices (https://book.leptos.dev/view/04b_iteration.html#option-3-memoized-slices).

My problem is that this is guess work - I have no intuition about what will be "good enough" (are there debugging tools that can tell me how long reactivity has taken?) and so I don't know how important it is to get this right. Changing it later will be quite a lot of churn however, so I need to get it "right enough" :-).

Integration with third party JS utils that change the Dom

Specifically Highcharts. I realise this isn't really a Leptos specific issue, and I appreciate Leptos going out of its way to be helpful (https://book.leptos.dev/web_sys.html), but are there any examples of giving a "real" element over to a third party to control?

Hot reload

I read that HMR works, with caveats. Am I correct in thinking that if the front end has a whole bunch of state (e.g. the DB struct) then as long as I only tweak things within the view! macro (or associated builder) then that state is preserved? If not then I assume I can always [de]serialise the DB to local storage as a workaround (another benefit of "one big blob of data" although obviously component local state won't be saved).

Tailwind

I know Leptos and Tailwind (and Trunk) are all friends, but there are open issues about Tailwind and Leptos (e.g. #2890). Is there anything special I need to be aware of? I was also thinking of using DaisyUI, but I assume that has no impact on Leptos?

What do you wish you had done/known before starting your first Leptos project?

If you are still here - I'm impressed and thankful :-).

Thanks!

[gbj]

So first I'll say, if you're a Discord user I'd suggest joining our Discord as there are a number of very helpful people there who respond to questions in real time, and it can be an effective format for this kind of back and forth.

To your questions:
0. If you're just doing client-side rendering, things are fairly simple and straightforward. Amen with regard to Rust or rescript haha.

1. Bootstrapping: You're correct, cargo-leptos mostly serves to coordinate the server and client rebuilds. Stick with Trunk for your use case.
2. Builder API: No perf difference for CSR, correct.
3. Version: I'd probably just start with 0.7. The book has not been updated but none of what's described in the early chapters has breaking changes.
4. Storybook: No.
5. Big blob of state: One very nice feature you can use in 0.7 is the introduction of reactive stores, which provide deeply-nested reactivity without nested signals, and little overhead. These aren't documented super well yet but take a look at the stores example in the repo if you want to use them. You can have a single big Store and share Field<T> via props or via context, and maintain fine-grained reactivity. You are correct about context (it is basically free w.r.t. performance, or O(1) anyway).
6. Integrating with JS: The chapter you link shows exactly how to get access to a real element; use wasm-bindgen to call out to the JS function and pass it that element.
7. Hot reload: There's no HMR in general, and no hot-reloading support in Trunk. State will not be preserved across reloads. Your suggestion of serializing your state blob into localStorage and reading from it again is a perfectly fine idea and ~trivial to implement (an effect that reads from the store). See the todomvc example for how to read/write from localStorage if you need help.
8. Tailwind The open issue is just a "how do I set up my Tailwind config to detect certain strings" and (IIRC, scanning it here again) is resolved and is just waiting for someone to add it to docs or tweak an example. There should be no issues AFAIK.

[yatesco]

thanks @gbj - your attitude, clarity, technical expertise and general attitude (that I've seen here and on reddit) is a significant part to betting on Leptos :-)