[6.x] Inertia #12610
Merged
[6.x] Inertia #12610
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
booting callbacks need to be first because the component needs to be registered in order to get resolved by inertia. components need to queued and then all actually registered later because they need be resolved by inertia before the vue app is started.
The View.vue was basically already the page component, but the props from the blade view are moved to the server. This can obviously be cleaned up, but I converted it with as few changes as I could.
…tural line background shows via a server prop remove globally registered component
…ses an error when returned through inertia.
# Conflicts: # src/Http/View/Composers/JavascriptComposer.php
Previously they were made available to the root vue app since they'd be used one-time from blade. But now that there is always going to be a layout vue component, they are no longer at the top level. Making them global for now, but they'll eventually get moved into their respective intertia page components.
…ever see a 404 outside since you'd get redirected to the login page
- fix additional breadcrumbs not appearing correctly - clicking nav will immediately update nav, but the breadcrumbs only load when the request is done - clicking breadcrumb will immediately update both. - this gives the illusion of more instant requests without breadcrumbs popping in incorrectly
…king the nav. The 'active' logic is more complicated than matching a url. NavItem->isActive can probably be converted to js later.
# Conflicts: # resources/views/components/breadcrumbs/dropdown.blade.php # resources/views/components/breadcrumbs/index.blade.php # resources/views/components/docs-callout.blade.php # resources/views/components/view-site-button.blade.php
…utside layout breaks things because changing layouts screws up the props
… redirect. An inertia visit screws up because of the layout change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR converts the Control Panel to an Inertia app. ✨
Typically, requesting a non-Inertia page will load it in a modal to show you've got an error.
In our case, it'll just do a full reload instead. That way non-Inertia pages will continue to "just work".
Pages should feel much faster now. A bunch of the overhead that you'd get on every request now only needs to happen on the first request.
This PR is the initial wiring up to get to concept sorted out. Not every page has been converted to Inertia - non Inertia pages will trigger those full page reloads in the mean time. Additional PRs will come to bring over the rest of the pages.