-
-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Some thoughts on the Lapis router #710
Comments
I've been meaning to add a more formal way to reorganize the bodies of actions into separate modules, I pushed a patch that introduces a system that works just like views for actions:
I decided to go with lazy loading, what the means is when the app boots not all the actions will resolve to their modules. The modules are loaded on request and cached via |
@leafo how should I provide capture_errors or capture_errors_json handler if action have to return html or json depending on request header 'Accept'? |
Is it possible to use 'capture_errors' handler with lazy loading of actions with the value true? |
No, you would instead have the
So It runs capture_errors fn, =>
if accept_json @
return json: { errors: @errors }
render: true This combines the logic from both the
accept_json = =>
if accept = @req.headers.accept
switch type accept
when "string"
return true if accept\lower!\match "application/json"
when "table"
for v in *accept
return true if v\lower!\match "application/json"
false |
@leafo thank you for your work and for answer! Yes, I went this way and wrote my own capture error handler. Would you make that common things as a part of Lapis? |
So, generally speaking the When |
It is clear. Thank you! One more thing. It would be grate if it is possible to choose default handle_error function while using actions as views (with arg true instead of function). It will makes code more clear and decrease boilerplate in action functions. For now it looks like this: for name, action in pairs(Routes) do |
Closing this since the original request has been addressed for some time now. |
Accept strings as well as functions
Similar to how the return table of an action takes the require path of a view instead of the view itself, the router also taking the require path of an action instead of the action function itself feels like it would fit here.
Merge respond_to into match
Instead of needing to wrap actions with the helper function
respond_to
to extract the correct function for a request, it would be handy if this functionality was simply built in tomatch
since it seems designed to be paired specifically withmatch
anyway.With both proposals in place, our routes could go from
to
Pseudocode
The text was updated successfully, but these errors were encountered: