Logged-in Views

Developer

These are the views available to a registered, logged in user: the dashboard and the account management screens that surround it, plus the registered-user side of the booking flow shared with Guest Views. Every view listed below was redesigned during this engagement, covering both the UI and the logic behind it.

Dashboard Views

The dashboard lives under resources/views/registered_user/, a folder introduced for this engagement and separate from the legacy front_end/ folder. userdashboard.blade.php is the main account dashboard, and it is also the clearest real-world example of the WashCardTemplate component’s dual-mode design described in Architecture & Codebase.

Each active order is rendered through the same component used on the public homepage, switched into dashboard mode:

<x-card.wash-card-template
    mode="dashboard"
    :plan-name="$firstService->name ?? 'Service'"
    :image-src="$serviceImg"
    :is-premium="$isPremium"
    :current-price="$currentPrice"
    :original-price="$originalPrice"
    :booking-date="$bookingDate"
    :time-slot="$timeSlot"
    :plan-id="$serviceId"
/>

The view maps each order’s service ID to a display image, an overlay color, and a feature list through small lookup tables ($planImages, $planOverlays, $planFeatures, $planMeta), keyed off config('carwash_plans...') IDs rather than hardcoded values. This is the same component, the same markup, and the same configuration source used to display plans on the homepage; only the mode prop and the data passed in change.

The other dashboard and account views are:

• front_end/orderdetails.blade.php: order history and detail view
• front_end/account_details.blade.php: account details and profile
• front_end/change_number.blade.php: phone number change flow
• front_end/my_addresses.blade.php: saved addresses

These remain under the legacy front_end/ folder rather than registered_user/; only the dashboard itself was placed in the new folder.

The Shared Booking Flow

Logged in users place one-time orders through the same three step flow as guests, described in detail in Guest Views. UserOrderController is the logged in equivalent of GuestOrderController, and several of the Blade views are shared between the two rather than duplicated.

In practice, a logged in user moving through this flow skips or shortcuts a few things a guest has to do:

• No phone verification step at checkout. The user’s number was already verified at registration, so the entire name, email, phone, and OTP section of the checkout view is hidden, and the layout collapses to a single column.
• Vehicle selection becomes a dropdown of the user’s saved vehicles (Auth::user()->vehicles) on the location and time step, with an “Add New Vehicle” modal available inline, rather than filling in vehicle details from scratch on step one.
• The step indicator shown to guests (<steps-display>) is hidden throughout, since the surrounding dashboard navigation already orients a logged in user.

Route Naming Refactor

As part of this work, the routes serving the account management views were renamed to follow RESTful, resource style paths, consistent with the structural recommendations in Architecture & Codebase. This was implemented in commit b4018c79edf310e97ae71f62550316048ecd1c4f.

Before the change, web.php defined these routes:

Route::get('/myAddresses', [...UserController::class, 'myAddresses'])->name('myAddresses');
Route::get('/accountDetails', [...UserController::class, 'accountDetails'])->name('accountDetails');
Route::get('/changenumber', [...UserController::class, 'changenumber'])->name('changenumber');
Route::get('/myvehicles', [...UserController::class, 'myvehicles'])->name('myvehicles');

After the change:

Route::get('/my-address', [...UserController::class, 'myAddresses'])->name('myAddresses');
Route::get('/my-account', [...UserController::class, 'accountDetails'])->name('accountDetails');
Route::get('/my-number', [...UserController::class, 'changenumber'])->name('changenumber');
Route::get('/deleteaccount', [...UserController::class, 'deleteaccount'])->name('deleteaccount');
Route::get('/my-vehicles', [...UserController::class, 'myvehicles'])->name('myvehicles');

Route names (myAddresses, accountDetails, and so on) were kept stable throughout, so the change does not break anywhere route() is called by name. Only the literal URL paths changed, alongside the addition of the new deleteaccount route.