Query Params

Model

In the weather API, besides the city, we also have two variables: units (metric / imperial) and forecast days.

Add them to the path model as query params and some helpers:

Query values are part of Routing.

app.gox

type Path struct {
	Route Route `path:"/ | /:CityID"`
	CityID int
	Units *driver.Units `query:"units"`
	Days *int `query:"days"`
}

// Get the days value from the query.
func (p Path) days() int {
    // Default value.
	if p.Days == nil {
		return 7
	}
	return min(max(*p.Days, 1), 7)
}

// Helper to convert days back to a query value.
func daysQuery(days int) *int {
	if days == 7 {
		return nil
	}
	return &days
}

// Get the units value from the query.
func (p Path) units() driver.Units {
    // Default value.
	if p.Units == nil || *p.Units != driver.Imperial {
		return driver.Metric
	}
	return driver.Imperial
}

// Helper to convert units back to a query value.
func unitsQuery(units driver.Units) *driver.Units {
	if units == driver.Metric {
		return nil
	}
	return &units
}

Query params use reference types in our case. Otherwise, they get a zero value and always appear in the URI. Decoding and encoding of query params are provided by go-playground/form v4. Refer to its documentation for all supported features.

elem (d dashboard) daysNav(units driver.Units) {
	<ul>
		~(for i := range 7 {
			~{
				days := i + 1
			}
			<li>
				<a
					class="secondary"
					(doors.ALink{
						Model: Path{
							Route: Dashboard,
							CityID: d.cityID,
							Days: daysQuery(days),
							Units: unitsQuery(units),
						},
					})>
					~(days)
					~(if days == 1 {
						 day
					} else {
						 days
					})
				</a>
			</li>
		})
	</ul>
}

To maintain the days value, the units nav accepts the current days value:

elem (d dashboard) unitNav(days int) {
	<ul>
		~(for _, units := range []driver.Units{driver.Metric, driver.Imperial} {
			<li>
				<a
					class="secondary"
					(doors.ALink{
						Model: Path{
							Route: Dashboard,
							CityID: d.cityID,
							Days: daysQuery(days),
							Units: unitsQuery(units),
						},
					})>
					~(units.String())
				</a>
			</li>
		})
	</ul>
}

Next, derive days and units:

dashboard.gox

func WeatherDashboard(path doors.Source[Path]) gox.Comp {
	city := doors.DeriveBeam(path, func(p Path) int {
		return p.CityID
	})
	days := doors.DeriveBeam(path, func(p Path) int {
		return p.days()
	})
	units := doors.DeriveBeam(path, func(p Path) driver.Units {
		return p.units()
	})
	return city.Bind(elem(cityID int) {
		~dashboard{
			cityID: cityID,
			days: days,
			units: units,
		}
	})
}

type dashboard struct {
	cityID int
	days doors.Beam[int]
	units doors.Beam[driver.Units]
}

And establish binds:

elem (d dashboard) Main() {
	~/* ... */
	~(d.menu())
}

elem (d dashboard) menu() {
	<nav>
		~(d.units.Bind(d.daysNav))
		~(d.days.Bind(d.unitNav))
	</nav>
}

Let’s see how it works:

Effect

You may notice that query params are lost on location change. To mitigate that, we have two options: convert Change to a button that mutates path state, or subscribe the Change link to both units and days. The first option is genuinely better because it has a smaller re-render surface. But the second is a nice opportunity to learn the Effect feature.

Effect causes the closest dynamic parent to reload automatically on state change. It is a "React-style" API.


elem (d dashboard) Main() {
	~/* ... */
    ~// Refactor the change link into a separate component.
	~(d.change())
	~(d.menu())
}
elem (d dashboard) change() {
	~// Dynamic container proxy.
	~>(new(doors.Door)) <>
		~{
			// Read state values with "effect".
			days, _ := d.days.Effect(ctx)
			units, ok := d.units.Effect(ctx)
		}
		~(if ok {
			<a
				class="secondary"
				(doors.ALink{
					Model: Path{
						Route: Selector,
						Days: daysQuery(days),
						Units: unitsQuery(units),
					},
				})
				role="button">
				Change
			</a>
		})
	</>
}

First, notice the new syntax ~>. This is called proxy syntax in GoX. A proxy wraps the following element and can apply any transformation to it. Essentially, it is similar to passing an element to a function, but with semantic meaning: this element will be transformed somehow and will not be rendered as-is. In the case of a doors.Door proxy, this element turns into a dynamic container.

Second, notice that we ignored ok from the first effect call. Effect fails, returning false, only if the context is canceled because the dynamic parent re-rendered or unmounted, so it makes sense to check only the last call.

We also could have used a grouped Settings struct with days and units fields instead of managing those params separately. That is acceptable, but in general it is almost always better to derive smaller and more specific state values so you update precisely what needs to be updated. Doors is not built around a virtual DOM with diffs, and it compensates with rich state derivation mechanics.

Next: Active Link

Code