Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

smesj's avatar
Level 1

InertiaJs/React Controller Structure

Hey folks, I have a design pattern question for any of you experienced Inertia(react)/Larvel’ers out there! Love to collect any and all feedback as I am a solo developer on this project and just need someone to bounce some ideas off of.

So, for a little context. The project was spun up using Laravel breeze and incorporates InertiaJs/React The current design issue I am working through is this.... What is the best way to organise controllers?

Currently I have 3 relatively distinct types of controller:

  • View controller: A traditional controller that returns a react view component, reaches for the requisite data and pumps it into the component/view via props Use Case: pretty much all route able views
    /**
     * Show the form for creating a new case.
     *
     * @return \Illuminate\Http\Response
     */
    public function create()
    {
        $clients = Role::where('name','client')->first()->users()->get();
        $counsellors = Role::where('name','counsellor')->first()->users()->get();
        return Inertia::render('Admin/IntakeManagement/IntakeManagementCreate', [
            'clients' => $clients,
            'counsellors' => $counsellors
        ]);
    }
  • Resource Action? Controllers: A controller that simply provides access to a particular resource action via a route and redirects back to the previous view to force a re render/ re hydration of the data there to reflect the change. Use Case: Simple CRUD operations and to better facilitate flash messages.
    public function update($caseId, $userId)
    {
        $result = $this->caseService->addCaseUser($caseId, $userId);

        return redirect()->back()
            ->with('message', $result);
    }
  • API/JSON controllers: A controller that will act more along the lines of a REST api call. Will perform a specific action and/or return a json response. This approach is used in the more deeply nested components to allow access to information and rendering responsibility to the component itself by leveraging the react life cycles and useEffect vs having to have data piped in via props. Use Case: A Live chat app that can effectively act as a self contained micro app that can handle its own IO.
    public function index($caseId)
    {
        $case = CounsellingCase::find($caseId);
        $messages = $case->messages()->with('user')->get();

        return response()->json([
            'messages' => $messages,
        ]);
    }

My concern here is that I have these paradigms sort of peppered throughout my flat file structure of controllers and looking forward I can foresee this becoming some what of a on boarding or maintenance/readability issue having all of these approaches used kind of at random.

So my question to you smart folks is... How would you approach the situation? Would you try and stick to one particular approach (refactor controllers to essentially be all API or refactor to not return JSON and drill props down to where they are needed)? Or could it simply be organised better (API/JSON folder for controllers that behave this way and try to just keep things organised)?

Let me know!

0 likes
3 replies
drehimself's avatar
Level 35

The three cases you outlined here are what I use when using Inertia.

I look at cases 1 and 2 as "standard" Laravel practices (when building server-rendered apps) that have just been transferred over to Inertia.

Case 3 is still required in cases where you have to make AJAX requests. Depending on how interactive your app is, a lot of these might still be required.

In terms of organization, I would just try to keep the API routes (case 3) in a separate section in the routes file, or maybe even in a separate file that you include in your main routes file.

In terms of onboarding, if those people are already somewhat familiar with Laravel these concepts shouldn't be new. Communicate your file/organization structure and I think you should be fine.

2 likes
smesj's avatar
Level 1

Thanks for the input!

Do you think there would be value into trying to bucket these particular controller files? IE: try split controllers into sub folders such as API(maybe even "component"), Resource, Views or do you feel that wouldn't have much "bang for the buck" so to speak.

drehimself's avatar

@smesj Hmm, I think that's totally up to you.

I personally look at my routes file as the table of contents so subfolders for controller files will follow the structure I have in my routes file. So if your routes file separates "API routes" it would make sense to have a subfolder for them for your controllers.

1 like

Please or to participate in this conversation.