in a previous code review @dessalines mentioned that name-spacing did not turn out well for a previous UI project:

https://github.com/LemmyNet/lemmy-ui-leptos/pull/20/files#r1346348901

just wanted to highlight this so we can come to a consensus openly

I use an Arch spin as my daily driver, and playwright tests are not supported on that platform. This makes it impossible for me to run tests locally. We definitely want end to ends tests to make sure we don't introduce regressions. There are docs for running playwright in docker, which seems like the most obvious viable option.

Opening an issue from this discussion as promised.

Proposed file hierarchy

• src
  • lib.rs
  • main.rs
  • constants.rs
  • host.rs
  • cookie_middleware.rs
  • routes.rs
  • routes
    • home.rs
    • home
      • home_page.rs
    • login.rs
    • login
      • login_page.rs
      • login_form.rs
    • post.rs
    • post
      • post_page.rs
      • get_post.rs
  • layouts.rs
  • layouts
    • base_layout.rs
    • filter_bar_layout
  • contexts.rs
  • contexts
    • site_context.rs
    • theme_context.rs
  • common.rs
  • common
    • components.rs
    • components
      • icon.rs
      • text_input.rs
      • unpack.rs
    • serverfns.rs
    • serverfns
      • list_comments.rs
      • list_posts.rs
  • utils.rs
  • utils
    • derive_query_signal.rs
    • types.rs

Digest

For simplicity, I didn't list every file that exists in the project. Some things to call out:

• Uses newer, more idiomatic style of declaring modules. Refer to this blurb from the Rust book. This should make it easier to find module styles since there won't be a bunch of files all names mod.rs strewn throughout the codebase.
• Routes keep modules that are only related to what a given route/page as siblings (e.g. login_form.rs and get_post.rs, a component and serverfn respectively, listed above)
• Went with "Page" as a suffix instead of "Activity". Not a diehard on this change, but I'm unfamiliar with the convention of calling these "activities" instead of "pages", which threw me off at first.

Things to hash out

There are some things I'm still not sure of in this suggestion. For example, in this hierarchy, several serverfns (e.g. vote, save, etc.) are only relevant to one or a few components (vote buttons, content actions). It arguably makes more sense to colocate these with the relevant components instead of throwing them in the common serverfns directory. A similar case can be made for colocating the navbars and the logout serverfn with the BaseLayout since they're only ever used there. If we did do this approach, I could see a hierarchy like:

• layouts
  • base_layout.rs
  • base_layout
    • base_layout.rs
    • logout.rs
    • top_nav.rs
    • bottom_nav.rs

Or perhaps:

• layouts
  • base_layout.rs
  • base_layout
    • base_layout.rs
    • serverfns.rs
    • serverfns
      • logout.rs
    • components.rs
    • components
      • top_nav.rs
      • bottom_nav.rs

Thoughts?

Now that there is a rust library specifically for making requests for lemmy, it makes sense to shift to using that instead of the hand-spun one currently used in this repo.

Hello! I've been learning Rust for the last couple of years and just so happen to have used Leptos in my last personal project.

My background is in decades of web development of all types so I would very much like to contribute to Lemmy, specifically the new Leptos UI to start.

I have already been working on my own branch for a week or so to get familiar with the code base and dev environment. Things are going fine!

I was wondering how work pieces are managed in the project and it seemed sensible to start with an Issue to indicate that I would like to work on a part of the new app so that other people also working on the app can organize themselves with that in mind.

I've been working on bringing the Leptos homepage up to the function and graphic design of the current UI but using the SSR and hydration of Leptos and the widgets and tools of Daisy and Tailwind.

I'm happy to carry on with this and it would be great to have the blessing of the team. I'm also totally happy to move on to another part of the app or just collaborate and help with work other people have already started.

@phiresky mentioned in the maintainer chat that he has concerns about using leptos for the UI repo. While I think leptos is definitely a step up from inferno, I have my own concerns about it. To spur discussion, I'll make some pros/cons lists for leptos, solidjs with solid start (my first choice of leptos alternative), and nextjs (popular fullstack framework with many compatible libraries).

Leptos

Pros

• Lets devs make UIs in rust, an incredible and ergonomic language.
• Lightning fast
• WASM bundle for whole app sent to browser on first load, making client-side page changes very fast
• Great support for progressive enhancement and graceful degradation

Cons

• Rust's high learning curve will make it harder for many devs to contribute, especially frontend devs who are less likely to have used the language
• Very limited ecosystem; many useful libraries are maintained by only one person with few commits and seem likely to be no longer actively developed
• Documentation and other supplementary information is fairly limited
• All of the WASM being sent on first load could make first load time slower

SolidJS/Solid Start

Pros

• Performance on par with (and sometimes even better than) leptos
• Small bundle size
• Excellent tutorial
• Support for progressive enhancement/graceful degradation on par with leptos
• Semi-decent ecosystem compared to leptos
• React-like without many of react's footguns

Cons

• Relatively unused compared to other frameworks
• Solid Start is still in beta and will probably have bugs not present in other frameworks
• Ecosystem smaller than other fontend/fullstack frameworks like react, angular, and vue
• Supplementary learning materials outside of the official tutorial and docs sparse

NextJS

Pros

• Uses react, which is known by many frontend developers
• Batteries included(ish, at least compared to the other frameworks listed here).
• Very large ecosystem of compatible libraries that can be used.
• Easy to find supplementary learning materials compared to the other frameworks listed

Cons

• Uses react, with all the bloat and footguns it entails
• Support for progressive enhancement/graceful degradation lacking compared to leptos and solid start

This list was made off the top of my head from my experience working with these frameworks. I'm likely forgetting to include other useful information about them. Then, of course, there are many other frameworks to choose from (I'd say too many). I've heard svelte/sveltekit is both nice to develop with and fairly performant, although I have no first hand experience with it.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Update dependency @types/node to v20.14.5
• Update dessalines/lemmy Docker tag to v0.19.4
• Update pnpm to v9.4.0

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

@SleeplessOne1917 @dessalines

i was unable to get the new lemmy client to make any successful request apart from the home page content (list_posts) on the server side only.

i noticed the home page content has been commented out completely so i assume this was a known issue.

i have left all the code there and only added some prototype code to add the authentication header.

I noticed we're currently using icons from the charm icon pack, but it looks like our icon library supports a lot of different icon packages: https://github.com/Carlosted/icondata#icon-packages

It might be good to standardize or pick which ones we like going forward.

I've always been partial to either feather icons, but tailwind's hero icons look like they might be a good choice too.

Currently, the LemmyClient trait is implemented for both the awc client and a placeholder Fetch struct which uses gloo-net. I take it that the point of the browser client is to be able to make requests from the browser when needed. However, with Leptos's server function feature, I question if this is necessary: browser-side calls of server functions use a stub that uses the browser's native fetch API. With this in mind, is there a reason to keep this logic? Stripping it would make the client implementation much simpler.

Repo: https://github.com/Baptistemontan/leptos_i18n