SSR & file-based dynamic routes in src/_routes

[jaredcwhite]

Builds upon (and supersedes) PR #281 and resolves #379.

Lots to go on this but early results are very promising…

Here's what the server/roda_app.rb file looks like:

require "bridgetown-routes"

class RodaApp < Bridgetown::Rack::Roda
  plugin :bridgetown_ssr
  plugin :bridgetown_routes

  route do
    # Process routes in server/routes and src/_routes
    Bridgetown::Rack::Routes.start! self
  end
end

Here's what an example route looks like (src/_routes/items/[slug].erb):

---<%
r.get do
  params = r.params[:slug].split("-")
  render_with data: {
    layout: :page,
    title: "The ID…",
    results: "The ID is: #{params[0]}. Slug is: #{params[1]}"
  }
end
%>---

<p>The results are in:</p>

<p><strong><%= resource.data.results %></strong></p>

<pre>
  <%= resource.id %>
  <%= resource.relative_path %>
</pre>

[jaredcwhite]

Note to self: fix failing tests before final merge (duh)

[ayushn21]

Awesome stuff. That was a mammoth of a PR :D.

I can't say I understood everything but there was nothing bad that jumped out at me. Looking forward to having this in main!

Do you think it's worth duplicating bin/bridgetown to bin/bt? It's a tiny amount of code that's unlikely to change so duplicating the file isn't the big deal in my opinion. It'll avoid putting the onus on the developer to set up an alias and provide a concise way to invoke commands out of the box.

[ayushn21]

Is it worth replacing with test/**/*.rb instead of deleting this line?

[ayushn21]

Maybe it's worth putting this in development by default? I'd imagine the vast majority of people would only use it locally.

[jaredcwhite]

I guess the question is which DX is worse: installing the puma gem in production even if it's not required for a static site build, or not installing it even when someone might need to utilize SSR? I tend to think the latter would be annoying and we'd have to document it: "hey, wanna do SSR? you need to move puma out of development in the Gemfile…" hmm

[ayushn21]

Yeah fair point. It's not doing any harm outside the dev group and saves the need to go and look up some docs 👍

[ayushn21]

Just thinking out loud, I have no idea if this is even feasible.

For live reloading, I wonder if it'd be possible to use EventSource to write a message to the client to refresh itself? We'd need to create the connection to a live_reload endpoint and listen for messages; that bit is fairly trivial. We'd also need to have some kind of file watcher and write a message to the client when a file changes. Not sure how feasible that is.

Seems like it'd be an easier way to go about it than using websockets; and also a bit more technically "correct" I suppose since the client never needs to write anything in a live reloading scenario.

The polling approach in this PR at the moment works so definitely think we should proceed with that; but perhaps something to think about for the future?

[jaredcwhite]

For live reloading, I wonder if it'd be possible to use EventSource to write a message to the client to refresh itself? We'd need to create the connection to a live_reload endpoint and listen for messages; that bit is fairly trivial. We'd also need to have some kind of file watcher and write a message to the client when a file changes. Not sure how feasible that is.

TIL about EventSource!

I'm totally open to any push-based mechanism in addition to polling, or instead of (if it's reliable enough over non-localhost connections).

[jaredcwhite]

Do you think it's worth duplicating bin/bridgetown to bin/bt? It's a tiny amount of code that's unlikely to change so duplicating the file isn't the big deal in my opinion. It'll avoid putting the onus on the developer to set up an alias and provide a concise way to invoke commands out of the box.

I like that idea!

[ayushn21]

TIL about EventSource!

I'm totally open to any push-based mechanism in addition to polling, or instead of (if it's reliable enough over non-localhost connections).

I discovered them just yesterday myself! I stumbled upon this PR which adds an EventSource source to Turbo: hotwired/turbo#415

I'll create an issue for this once this PR is in main .... and add it to my never ending list of things to do :D

[KonnorRogers]

TIL about EventSource!
I'm totally open to any push-based mechanism in addition to polling, or instead of (if it's reliable enough over non-localhost connections).

I discovered them just yesterday myself! I stumbled upon this PR which adds an EventSource source to Turbo: hotwired/turbo#415

I'll create an issue for this once this PR is in main .... and add it to my never ending list of things to do :D

You may know EventSource under a different name, it's also called "Server Sent Events" we used them at Veue for our chat system.

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

[ricsdeol]

Hi, this is amazing project, but I didn't find how I render this _route/item/[slug].erb ?

I tried to use this example:

server/routes/count.rb

# Rename this file to hello.rb to try it out

class Routes::Count < Bridgetown::Rack::Routes
  route do |r|
    # route: GET /count
    r.get "hello"  do
      { oi: "friend from server" }
    end
  end
end

src/_routes/count/hello.liquid

<p><strong>Oi:</strong> {{ resource.data.oi }}</p>

src/_layouts/default.liquid

 {% render "count/hello" %}

 {% render "routes/count/hello" %}

And I get this error:

[Bridgetown]   Liquid Exception: Liquid error (line 10): No such template 'count/hello' in /home/ricsdeol/projects/leaning/count_teste/src/_layouts/default.liquid

Could you please give some examples using data from server ?
Is the server intended to be accessed only through JavaScript request?

[jaredcwhite]

@ricsdeol In case you didn't see my reply on Discord…

I think you don't need any of the examples except just the single src/_routes/count/hello.liquid file, and it should look something like this: https://gist.github.com/jaredcwhite/b14285934746202236db0b9bbdf2071a