Views on Create/Update/Delete actions

[matthewmueller]

@jfmario pointed out in the docs that the non-GET actions, e.g.

// Create a new user
// POST /users
func (c *Controller) Create(name string, age int) (*User, error) {}

// Show a user
// GET /users/:id
func (c *Controller) Show(id int) (*User, error) {}

// Update a user
// PATCH /users/:id
func (c *Controller) Update(id int, name string, age int) error {}

// Delete a user
// DELETE /users/:id
func (c *Controller) Delete(id int) error {}

Cannot have views. They will redirect back to Index or Show, unless you set Accept header to application/json.

This is following Rail's routing conventions that I find pretty good for mapping a domain to an API, despite there being some confusion around nested routes.

We'll need to decide if actions:

1. can't have views.
2. shouldn't have views.

Either is possible, the can't would probably be an error, the shouldn't would probably allow views on creates, but is just considered a bad practice.

[jmaister]

Why are you using PATCH and not using PUT? I don't know the difference here.

[matthewmueller]

See: https://rubyonrails.org/2012/2/26/edge-rails-patch-is-the-new-primary-http-method-for-updates

[jfmario]

Perhaps I was trying to do something that maybe shouldn't be supported when I noticed this and made the comment.

I made a "create" view that was supposed to accept the newly created widget and simply said "You have successfully created widget: <widget_name>." It just took me a minute to realize why I was seeing "Not Found" (b/c I hadn't made Index yet)

[matthewmueller]

Yep, makes sense! I can definitely see how that's confusing.

[vogtp]

Just playing around with bud...

Personally I would allow each method its own view. If the should not have views I'd create a warning.

The comment generated by bud new controller does not have further meaning, right?

I would like to have something like this:
// GET /x/:id/edit edit2.svelte

Defining method, path and view. Ofc sensible default values if omitted.

[vogtp]

OK, the example I used was not optimal. It looked nicer than the create (with the fancy :id ;-)

I was basically referring the the create "black magic" and since I see the points of "backwards compatibility" and "usual use case" I started to think about some sort of annotation to define the view.

[matthewmueller]

Ohhh... @vogtp do you mean that the comment // GET /x/:id/edit edit2.svelte would alter the default rendered view from view/x/edit.svelte to view/x/edit2.svelte?

Yes it's true that the comments don't currently do anything :)

[vogtp]

Yes that was my idea.
Of cause, while doing it I would have it change method and path as well.

This would add quite a bit of flexibility (and yes one could do nasty stuff as well ;).

[matthewmueller]

Ah cool yep. I can see how that would be nice, allowing you to switch routes and the default view all in one place.

Right now I'm leaning towards a custom routes package, similar to Rail's config/routes.rb that where you can override the default routing. There's a discussion here.

For swapping views, I'd like to additionally tackle type-safe props, so I'm bouncing around an idea of having something like:

func (c *Controller) Show() (view.View, error) {
  return view.ShowUsers{
    ID: 10
  }, nil
}

What do you think?

[vogtp]

To be honest I did not play long enough with bud to be able to see the pros and cons clearly and I am not much of a web developer (so I have no clue what ppl might expect).

It seems to be the more classically approach, so it might be more what ppl expect to find and it would probably add a even more flexibility. Also it adds to the learning curve for new users.

On the other hand with the annotation approach you'd get the configuration where the relevant code is. But probably it will be harder to detect configuration issues. Also it would be static and no way how you could prefix a base path.

All in all I think the annotation approach would be nicer while hacking in the beginning and the controller would give you more power and flexibility in the long run.