RFC: Support Static views

[matthewmueller]

Static Views

Views that don’t have an accompanying controller action are considered static views. Static views respond the same every time.

For example, most /about pages are static. You can create a static about page by creating view/about.svelte with the following:

<h2>All about Me!</h2>

Whenever reasonable, prefer static views over dynamic views. This is because Bud will eventually pre-render these pages and respond with long-term cache headers that can be placed behind a CDN.

Of course views that include client-side Javascript can also be static:

<script>
  const url = "https://corsanywhere.herokuapp.com/query1.finance.yahoo.com/v8/finance/chart/NET"
  const stocks = fetch(url)
    .then((res) => res.json())
    .then((stock) => stock.chart.result[0].meta)
</script>

{#await stocks}
  <p>Loading...</p>
{:then stock}
  <p>
    {stock.symbol} is currently trading at {stock.regularMarketPrice} USD.
  </p>
{:catch error}
  <p>Error fetching stock price</p>
{/await}

In the example above, when you first visit the page, it will show Loading... while firing off a fetch request from the browser. Once the stock data is loaded, it will re-render with the stock price. This is still a static view because the initial page data is the same every time.

[fahmifan]

What about give a postfix like about.static.svelte? So we could know it is a static page by it's name, also we can import any components

[matthewmueller]

That's an interesting idea! I like that it's clear from the filename and also allows for potentially more variations in the future (e.g. about.<variant>.svelte)

This would be in addition to the proposal above, since the above is a valid state your project could be in. A view without an action should at least behave correctly, but we can do better knowing that there's no controller action passing data down. So adding a postfix would need to provide additional benefits not achievable by the above.

[Panakotta00]

How about making dynamic views explicit?

Instead of a file path like /post/show.svelte -> post/:id and post/index.svelte -> /post
you could make them something like post/:id/index.svelte -> post/:id and post/index.svelte -> /post
which would be, in my opinion, more intuitive, as you actually can explicitly see where you are working with path parameters.

Static pages are then simply all pages that do not have a :param in their file path.

[matthewmueller]

It's an interesting thought. It reflects what the currently FE frameworks are doing too. I tend to agree that there's less thinking needed.

I think it'd be kind of strange if the views/ following this style, but the controllers/ didn't. I had considered merging controllers/ and views/ under actions/, but Go doesn't support dynamic import paths like import "action/posts/:id/comments". There might be an alternative solution, just requires more thought.

FYI, Static pages are more about if there's dynamic data (from a controller). Static pages could still totally respond to /user/:id, where you parse the :id on the client-side using something like routematch.

[Panakotta00]

Jeah that makes sense.

For static views.
If I understand correctly and use my proposed view stucture,
image you have a file /about/index.svelte for route /about and a blog/index.svelte for route /blog.
about would not need to be a dynamic page (doesn't need data from controller), but blog wants (to list f.e. blog posts).

Thats f.e. something i noticed which seems to be not possible in the latest version.
That you can have a route /blog hooked to a controller that returns the latest blog posts,
and a route /blog/post/<post slug> to show a specific blog...
i could make a route blog/<post slug> but I think from a design perspective this seems odd, as it requires me to work with a "blog" structure in go and a "blogs" variable in svelte.

I was not yet able to fully understand how bud opperates, but it doesn't seem like it analyzes the controller code much.
I think you could define if a view is static or not, by simply checking if a corresponding controller exists.
If it doesnt, it it is static.
Additionally, if possible, it would be cool if this code can check what the return values of the controller functions are, and if they have varaible names, because you could use this go syntax to send arbitary data and amount of variables to svelte...
this would sepperate the "view structure" and the "model" a bit from each other...
it should not reduce the ease of use at all, since the "bud new" command should still be able to create files easily like they work in the current way, where based on controller name a view, model and control gets created.
Just some more random ideas that came to mind.

[matthewmueller]

That you can have a route /blog hooked to a controller that returns the latest blog posts,
and a route /blog/post/ to show a specific blog

Custom routing is coming, but not available yet. For now I'd recommend keeping everything top-level. Nested paths would have the following routing: /posts/:post_id/comments/:id. This mirrors Rails, but could be surprising for newcomers used to how recent frameworks like Next.js work.

it doesn't seem like it analyzes the controller code much.

There's quite a bit of analysis actually. It figures out and wires dependencies within Controller, it parses request bodies into function signatures, etc. It's going to get much more complex as time continues, so I'm working on adding more tests now and tidying up the architecture a bit before doubling down on the generators.

I think you could define if a view is static or not, by simply checking if a corresponding controller exists.
If it doesnt, it it is static.

This is how we'd do it.

[matthewmueller]

Additionally, if possible, it would be cool if this code can check what the return values of the controller functions are, and if they have varaible names, because you could use this go syntax to send arbitary data and amount of variables to svelte...

This is how it works today. func (c *Controller) Index() (name string) would send down export let name to Svelte. It's a bit broken right now with func (c *Controller) Index() string sending down export let _string. It should just be export let string. Contributions welcome!