Walkthrough

Added a new public method App.ReloadViews() that mutex-protected reloads the configured view engine, a new exported error ErrNoViewEngineConfigured, unit tests covering success/error/no-engine/interface-nil cases, and corresponding API documentation.

Changes

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant App
    participant Mutex
    participant Engine

    Client->>App: ReloadViews()
    App->>Mutex: Lock()
    Mutex-->>App: Locked

    alt Views configured (non-nil)
        App->>Engine: Load()
        alt Load succeeds
            Engine-->>App: nil
            App-->>Client: nil
        else Load fails
            Engine-->>App: error
            App-->>Client: wrapped error ("fiber: failed to reload views: ...")
        end
    else No view engine configured (nil or nil-pointer)
        App-->>Client: ErrNoViewEngineConfigured
    end

    App->>Mutex: Unlock()

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Reason: small, focused feature adding a public API, a new error constant, tests, and docs. Review should validate concurrency (mutex usage), nil/interface checks, error wrapping, and test coverage.
• Pay special attention to:
  • app.go — correctness of nil vs. nil-pointer checks for the Views interface and proper mutex usage.
  • Error wrapping and message consistency ("fiber: failed to reload views").
  • Tests in app_test.go verifying the interface-nil pointer case.

Suggested labels

✏️ Feature

Suggested reviewers

• sixcolors
• ReneWerner87
• efectn

Poem

🐰 I hopped in, templates ready to mend,
A mutex embrace, then Load() to send.
Three tests nodded—success, error, and nil—
Views reloaded, the app hums still. 🥕

Pre-merge checks and finishing touches

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Summary of Changes

Hello @gaby, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the application's view management by introducing a ReloadViews method, which enables dynamic reloading of view templates without requiring a server restart. It also standardizes error handling for view engine configuration by defining and utilizing a new shared sentinel error, ErrNoViewEngineConfigured, ensuring more consistent and predictable error responses.

Highlights

• New ReloadViews Method: A new ReloadViews method has been added to the App struct, allowing on-demand reloading of the configured view engine. This is particularly useful for development workflows to pick up template changes without server restarts.
• Standardized Error Handling: A new reusable sentinel error, ErrNoViewEngineConfigured, has been introduced. The ReloadViews method now uses this shared error when no view engine is configured, improving consistency and testability.
• Comprehensive Unit Tests: New unit tests have been added for the ReloadViews method, covering successful reloading, error propagation from the view engine, and the specific case where no view engine is configured.
• Documentation Update: The ReloadViews method has been documented in docs/api/app.md, including its signature and an example of how to use it.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.65%. Comparing base (aaad4cf) to head (55c984c).
⚠️ Report is 5 commits behind head on main.

@@           Coverage Diff           @@
##             main    #3876   +/-   ##
=======================================
  Coverage   91.64%   91.65%           
=======================================
  Files         115      115           
  Lines        9848     9858   +10     
=======================================
+ Hits         9025     9035   +10     
  Misses        523      523           
  Partials      300      300           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I have just tested this PR by using fsnotify to detect a change in the views and then triggering app.ReloadViews() through it. The function does not return an error, so I'm assuming the views have been reloaded. However, upon calling a reoute that uses one specific view that I had edited, I can see that the route still returns the outdated version.

I'm using the following engine:

		engine = html.New(cwd, ".html")

The reload happens like this (simplified):

		srv.watcher, err = srv.getWatcher(cwd+"/views", func(f string) {
			err := srv.app.ReloadViews()
			if err != nil {
				Error("error", err)
			}
		})

app is available in a shared context (srv, pointer) and the getWatcher method looks like this:

func (srv *Web) getWatcher(path string, callback func(f string)) (*fsnotify.Watcher, error) {
	watcher, err := fsnotify.NewWatcher()
	if err != nil {
		return nil, err
	}

	go func() {
		for {
			select {
			case ev, ok := <-watcher.Events:
				if !ok {
					return
				}
				if ev.Has(fsnotify.Write) {
					callback(ev.Name)
				}
			case err, ok := <-watcher.Errors:
				if !ok {
					return
				}
				Error("error", err)
			}
		}
	}()

	if err = watcher.Add(path); err != nil {
		watcher.Close()
		return nil, err
	}

	return watcher, nil
}

Either it is an issue that the ReloadViews runs inside a Goroutine, at which point this feature then appears to be of relatively little use, or the implementation doesn't work/has some side-effects that weren't clear.