Hello, @DaniruKun! This is your first Pull Request that will be reviewed by SourceLevel, an automatic Code Review service. It will leave comments on this diff with potential issues and style violations found in the code as you push new commits. You can also see all the issues found on this Pull Request on its review page. Please check our documentation for more information.

There seems to be a mix of EEx and {} syntax used for interpolation. Can we use only <%= %> syntax?

We don't want to make the whole front page a live view because it's resource intensive and a popular page. Can you make only the search component a live view instead?

There seems to be a mix of EEx and {} syntax used for interpolation. Can we use only <%= %> syntax?

We don't want to make the whole front page a live view because it's resource intensive and a popular page. Can you make only the search component a live view instead?

@ericmj To answer point 1. - technically we can, but it's now considered the "old" syntax that will be deprecated at some point in favour of the HEEx way of doing things, and I think the .heex extension makes it very clear where it can be used.

About 2. - what do you mean?

In my implementation, nothing changes in terms of page load times (or first contentful paint) - the request starts out as a regular HTTP GET and gets upgraded to a WS connection if the client supports it. Of course, you will see a slight increase in memory usage because of the stateful nature of LiveView, however as you'll see we never keep more than 5 package results in the LiveView socket state.
The expensive stats you see on the home page are presented only once, and are then cleared from the state to save memory.
In terms of extra CPU usage, the periodic queries will have a small impact, but also save an extra request and resources that would have otherwise been spent on presenting the package index page with more than 5 results 😊

All things considered, the benefit from the better UX and less page loads outweighs the extra cost of memory and CPU imho.

To answer point 1. - technically we can, but it's now considered the "old" syntax that will be deprecated at some point in favour of the HEEx way of doing things, and I think the .heex extension makes it very clear where it can be used.

Ah yes, we should use the HEEx syntax 👍 .

what do you mean?

Isn't it possible to make section of the page a liveview instead of making the whole page a liveview?

Isn't it possible to make section of the page a liveview instead of making the whole page a liveview?

Maybe you are talking about Live Components? Even then, they still require a LiveView - you have to replace the default Phoenix Controller with it regardless.

If using a small liveview component in a larger page means that the whole page needs to be changed, like here: https://github.com/hexpm/hexpm/pull/1080/files#diff-ae87547521f78e46f7a0c59f22cc2715f4af4e0b6fc213c3b68b45a08b6456c5R58 and here: https://github.com/hexpm/hexpm/pull/1080/files#diff-ae87547521f78e46f7a0c59f22cc2715f4af4e0b6fc213c3b68b45a08b6456c5R132, along with replacing the controller action with a liveview this does not seem feasible or maintainable.

When looking at the data sent over the websocket after the page load it looks like almost the entire page is sent over the websocket again. I don't understand how render time and CPU usage can be unaffected when it's doing this?

@DaniruKun you can do live_render(conn, SomeLiveView) in a regular dead view: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.Helpers.html#live_render/3

This way, you can convert only the search input to LiveView+HEEx, leaving the remaining of the page untouched. I believe this is what @ericmj's proposing.

When looking at the data sent over the websocket after the page load it looks like almost the entire page is sent over the websocket again. I don't understand how render time and CPU usage can be unaffected when it's doing this?

To clarify, the concern is not the rendering time per se, but mostly doing the queries twice. It will most likely be fine but given this is the home page, which is likely the most accessed page, starting with only the widget style seems like a sane choice to assess the impact it will have on prod.

Ah got it, now it's clear. I'll try out that helper then, thanks!

Implemented it using @josevalim 's suggestion, now the old controller and router should be untouched, and the search LiveView is much simpler. Feel free to test locally with the seeded data and propose adjustments to the event parameters 🙂

I adjusted the template to no longer have a dangling datalist, and instead have my own custom div since as far as I tried, it's kind of impossible to properly make native datalist element options re-render. Plus with the custom approach, you have direct links to the results.

I like this improvement but cannot merge it in its current state because the browser's dropdown overlaps the datalist making it not usable. I think one solution could be to replace the browser's dropdown with our own instead of using a datalist.

Ah you mean the browser's autocomplete. I think it can be disabled, then there shouldn't be any overlap anymore. The datalist is already gone like I said, so it shouldn't be a problem.

@ericmj I disabled any form of browser autocomplete/caching for the form, so now it should be clean. Please check that it is the desired behaviour.

I still think that it should be a dropdown because we can add it to the search in the navbar and it's jarring when the content below the search results jumps around when the search results change.

Closing because PR is stale.