Describe Current Leptos Features Presently Missing From The Book

[diversable]

There have been a few Leptos features which were brought up in discussion which should be described in the book (see reference, below).

It is possible that some of these features should be listed in a new section, "Part 3: Advanced Topics" (see here for that issue: #8)

• <Provider /> - see "Global State Management" Chapter - add new <Provider /> component description #3

• <Portal>s -
  see: https://github.com/leptos-rs/leptos/releases/tag/v0.5.2

• #[slot]s -
  see https://github.com/leptos-rs/leptos/tree/main/examples/slots

• #[prop(attrs)] -
  see: https://github.com/leptos-rs/leptos/releases/tag/v0.5.0-rc1

• slice!() macro -
  see: https://github.com/leptos-rs/leptos/releases/tag/v0.5.2

• directives -
  see: https://github.com/leptos-rs/leptos/releases/tag/v0.5.2

• Callback -
  see: https://github.com/leptos-rs/leptos/releases/tag/v0.5.0

• window_event_listener use cases -
  see: https://docs.rs/leptos/latest/leptos/fn.window_event_listener.html & https://github.com/leptos-rs/leptos/releases/tag/v0.5.0

• TextProp -

• ViewFn -

• MaybeProp -

• Changing signals reactive context to parents or other items in the tree -

• signal features: batch, untrack, on_cleanup -

• Describe resources that depend on other resources & resources that update with actions - "Loading data with resources" chapter

• Use cases for use_navigate - "Routing" section, chapter __
  see https://docs.rs/leptos_router/latest/leptos_router/fn.use_navigate.html

• Static routes - "Routing" section, chapter __
  see: https://github.com/leptos-rs/leptos/releases/tag/v0.5.0

• logging with Leptos -
  See: https://github.com/leptos-rs/leptos/releases/tag/v0.5.0 - "The log!, warn!, and error! macros have been moved into a separate logging module to avoid naming conflicts with the log and tracing crates. You can import them as use leptos::logging::*; if desired."

• ...

Pt 2: SSR-related features

• common / recommended middleware

• explicitly talking about changing headers and status in responses for server bodies

• ...

As of yet, I'm not sure where these features should fit into the book: suggestions, help writing these up, and other topics missed in the list above, are all welcome.
The list above will be updated with new suggestions from any comments on this issue.

---

leptos-rs/leptos#2007 (comment)

"""

i think one problem is discoverability - there are quite a few (mostly recent) features that were added but aren't included in the book (#[prop(attrs)], #[slot]s, , slice!, Callback, TextProp, ViewFn, MaybeProp, extra signal stuff (batch, untrack, on_cleanup)) that I think could be beneficial for people to know of.

Maybe a full discussion of the features doesn't need to be included in the book, but simply mentioning that these exist could be helpful, so that people don't try to reinvent the wheel. For example, the Components and Props section could mention (and briefly describe the use cases of) #[slot]s, the handy types like Callback, TextProp, MaybeProp and ViewFn, with links to the docs.rs pages. Same thing in the Reactivity section, the signal helper functions batch and untrack could be briefly mentioned.

Perhaps a more ambitious undertaking could be restructuring the leptos modules. Currently, pretty much everything is just re-exported in leptos::*, which makes it easy to use in code but difficult to navigate the docs. Maybe having more public modules (e.g. components for all the components provided by leptos, props for all the extra structs) but still re-exporting in the crate root could help. Maybe some functions like batch and untrack could be moved to be associated functions of the Signal type?

...
"""

[benwis]

I'd add

• Changing signals reactive context to parents or other items in the tree
• More explicitly talking about changing headers and status in responses for server bodies
• Common/recommended middleware
• Resources that depend on other resources, resources that update with actions
  That's off the top of my head. Thanks for doing this!

[diversable]

I'd add

• Changing signals reactive context to signals
  ...

thanks for the additions, @benwis!

I was hoping you could you explain a little more about what you mean by "changing signal's reactive context to signals" though..? thx!

[benwis]

I'd add

• Changing signals reactive context to signals
  ...

thanks for the additions, @benwis!

I was hoping you could you explain a little more about what you mean by "changing signal's reactive context to signals" though..? thx!

Edited the original, I missed a word 👍