Closed ledermann closed 2 years ago
I found an example demonstrating a more serious conflict:
class DashboardController < ApplicationController
# Define shared data with a block calling a method which exists in THIS controller only
inertia_share something: -> { foo }
def index
# within this method an exception is raised
raise RuntimeError
end
private
def foo
# something
end
end
Now, bad things happen when user goes to /dashboard
:
index
method is executed, the inertia_share block is added to the global list of shared data blocks.index
method runs and the exception is raised. foo
method, which is defined in DashboardController,
not ExceptionController
. My PR #17 fixes things like this. @bknoles and @BrandonShar, please think again about merging #17 :-)
I wrote this in #17 , but reiterating here:
The second situation is definitely something that should be fixed... but on the first example, I think I would prefer to have the shared data available within the ExceptionsController.
Closing due to inactivity. Feel free to re-open if we missed an issue that still exists!
The current implementation of
inertia_share
is based onbefore_action
, so the shared data is executed by all means before the action is processed. Even if the controller action raises an exception, which I don't think is a good thing.Think of this application using a custom exception handler to response with Inertia for exceptions, like this:
This works fine, see my my demo Rails app PingCRM for a live example: https://pingcrm.ledermann.dev
Now, lets assume an action raises an error, like this:
When the error occurs, the exception handler strikes in and renders the
Error
Page instead of theDashboard
page, but the shared data ofApplicationController
andDashboardController
is included as props. too. This is not optimal, because in case of an exception the response should be as simple as possible.I would like to propose again to merge my PR #17 because it has not this issue.