What is the difference between data and action

[aszenz]

I didn't find any docs on what action does, the types seem similar to data.

Is it related to handling POST requests on the route?

[aszenz]

Seems like yes its for non get requests as per the Server Request package docs

Note that in server-rendered Route modules, your data function will handle GET requests (and will not receive any POST requests), while your action will receive POST (and other non-GET) requests.

[dillonkearns]

Next i tried to look at the docs site, I expected it to be mentioned in server rendered routes or request time routes section.

Thanks for sharing that @aszenz! Maybe a page specifically on actions would be an intuitive way for people to find that information, and there's plenty to write about that topic so seems like a good idea to have a page dedicated to that 👍

Why is action data wrapped in a Maybe in RouteBuilder.App?

If you load a page in your browser (uses GET method to hit the server), then app.action will be Nothing. If you hit the submit button, then app.action will have the Just <ActionData> value there. This is progressively enhanced, so if you submit an elm-pages Form with the Elm app hydrated (JavaScript enabled), then it will submit the data without a hard page load (XHR request). If you have JavaScript disabled (uncommon, but could happen if the user immediately submits a form before the JS hydrates, especially on slow devices/connections), then you will end up with app.action having Just <ActionData> right away in that case.

If data is not run during a post request, then how can i get app.data in view function, using debug.log i see data is computed after action in a post request.
elm-pages revalidates your Route's data after the action is run. This is to prevent stale data on the page. If you use concurrent form submissions (Pages.Form.withConcurrent), then it will cancel any redundant data reloads from the client-side so that it only keeps the last data reload HTTP request needed to get fresh data.

In function withStatusCode : Int -> Response data Never -> Response data Never, why does it return error type as Never, this turns out to cause type errors when returning error page for another http method in the same action function

If you render an ErrorPage, then the status code is determined from ErrorPage.statusCode : ErrorPage -> Int. So the intention of this type is to prevent defining a status code where there already is one. Maybe the way I'm doing that is problematic, though, I'll need to think about that a bit more (or if you can clarify or give an example that causes an issue that would be helpful, too).

[aszenz]

@dillonkearns

If you render an ErrorPage, then the status code is determined from ErrorPage.statusCode : ErrorPage -> Int. So the intention of this type is to prevent defining a status code where there already is one. Maybe the way I'm doing that is problematic, though, I'll need to think about that a bit more (or if you can clarify or give an example that causes an issue that would be helpful, too).

That makes sense but what if i'm defining a response with no error type that should work but doesn't.

action :
    RouteParams
    -> Server.Request.Request
    -> BackendTask.BackendTask FatalError.FatalError (Server.Response.Response ActionData Never)
action _ _ =
    BackendTask.succeed
        (Server.Response.plainText "Not supported"
             |> Server.Response.withStatusCode 405
        )
        |> BackendTask.allowFatal

This is a simple action that returns not supported for non-get requests, problem is RouteBuilder.ServerRender action only accepts responses of error type ErrorPage as see here:

{-| -}
serverRender :
    { data : routeParams -> Server.Request.Request -> BackendTask FatalError (Server.Response.Response data ErrorPage)
    , action : routeParams -> Server.Request.Request -> BackendTask FatalError (Server.Response.Response action ErrorPage)
    , head : App data action routeParams -> List Head.Tag
    }
    -> Builder routeParams data action
serverRender { data, action, head } =

[aszenz]

I also wonder if it makes sense to create a helper actionNotSupported many of the routes like search pages are often GET only with filters submitted in query params

[dillonkearns]

Thanks for giving an example for the Never issue, I'll take a look at that.

Regarding the actionNotSupported idea, or the general idea of indicating when something is unsupported in a server-rendered data or action function, I've been thinking about this and the general idea I have in mind is that there needs to be some way to give an error that can then be picked up by the client and handled (or ignored).

Something akin to the RemixJS concept of a CatchBoundary. I think it would make sense to be able to handle this by registering an onError Msg (either in a Route Module, and/or in Shared.elm).

I'm not sure exactly what would indicate an error, though... maybe just an HTTP response in the 400 range? And I'm not sure how you would send text or data through that error. Maybe a way special response type for that? I'm open to ideas there.

[aszenz]

I have in mind is that there needs to be some way to give an error that can then be picked up by the client and handled (or ignored)

Not all errors are related to the client (i assume you mean the front-end ui here), actionNotSupported error is useful in case someone is messing with the website via curl / crawlers.

I currently find the data and action abstraction hard to understand, I'm more familiar with a normal controller kind of abstraction, handle a request and emit a response which can be html/text. I guess that the current abstraction maybe necessary for hydrating data for page navigations.