Skip to content

Commit f5999f5

Browse files
authored
3.x (#70)
* Copy 2.x docs to 3.x * Update Livewire components documentation * Remove 'jet-' component prefix from examples * Apply recent 2.x changes to 3.x * Add dark mode section * Configure 3.x in Vuepress * Update Vuepress search path * Update default redirect * Remove remaining references to publish the `vendor/jetstream` directory * Formatting * Update screenshot
1 parent 8f1ae6c commit f5999f5

23 files changed

+1481
-3
lines changed

Diff for: .vuepress/3.x.js

+37
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
module.exports = [
2+
{
3+
title: "Getting Started",
4+
collapsable: false,
5+
children: [
6+
'introduction',
7+
'installation',
8+
'concept-overview',
9+
'building-your-app',
10+
],
11+
}, {
12+
title: "Features",
13+
collapsable: false,
14+
children: prefix('features', [
15+
'authentication',
16+
'registration',
17+
'profile-management',
18+
'password-update',
19+
'password-confirmation',
20+
'two-factor-authentication',
21+
'browser-sessions',
22+
'api',
23+
'teams',
24+
]),
25+
}, {
26+
title: "Stack Features",
27+
collapsable: false,
28+
children: prefix('stacks', [
29+
'livewire',
30+
'inertia',
31+
]),
32+
}
33+
]
34+
35+
function prefix(prefix, children) {
36+
return children.map(child => `${prefix}/${child}`)
37+
}

Diff for: .vuepress/config.js

+2-1
Original file line numberDiff line numberDiff line change
@@ -24,7 +24,8 @@ module.exports = {
2424
],
2525

2626
sidebar: {
27-
'/2.x/': require('./2.x')
27+
'/2.x/': require('./2.x'),
28+
'/3.x/': require('./3.x')
2829
},
2930
},
3031
}

Diff for: .vuepress/theme/index.js

+1-1
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ module.exports = {
33

44
plugins: [
55
['@vuepress/search', {
6-
test: ['/2\.x/'],
6+
test: ['/3\.x/'],
77
}]
88
],
99
}

Diff for: 3.x/README.md

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
<meta http-equiv="refresh" content="0;url=/2.x/introduction.html" />

Diff for: 3.x/building-your-app.md

+71
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
# Building Your App
2+
3+
[[toc]]
4+
5+
## Introduction
6+
7+
After installing Jetstream, you may wonder how to actually start building your application. Thankfully, since Jetstream handles the configuration of all of the initial authentication and application scaffolding, you can get started right away!
8+
9+
After installing Jetstream, the code is yours. The templates belong to your application and can be modified as you see fit. Jetstream is just a starting point. You do not need to worry about keeping your user interface "compatible" with future Jetstream releases because each Jetstream release is simply an entirely new iteration of the starter kit. In other words, Jetstream is not a package or administration dashboard that you will "update" in the future. It is a starter kit scaffolding for Laravel and, after it is installed, the templates are entirely yours to maintain.
10+
11+
:::tip Livewire & Inertia
12+
13+
Before diving into Jetstream, you should be familiar with how to use [Laravel Livewire](https://laravel-livewire.com) or [Inertia](https://inertiajs.com). Jetstream relies heavily on these technologies to provide a first-class user and developer experience.
14+
:::
15+
16+
## Application Dashboard
17+
18+
After authenticating with your application, you will be redirected to the `/dashboard` route. This route is the home / dashboard screen of your application. When you are using the Livewire stack, this page is rendered by the `resources/views/dashboard.blade.php` Blade template. When using the Inertia stack, the screen is rendered using the `resources/js/Pages/Dashboard.vue` component.
19+
20+
If you open the dashboard template / component for your application, you will see that it extends the application's primary "layout" component. This layout defines the overall look and feel of the interior of your application. When using Livewire, this layout is defined by the `resources/views/layouts/app.blade.php` template and rendered via the `App\View\Components\AppLayout` component class. When using Inertia, your application layout is defined by the `resources/js/Layouts/AppLayout.vue` component.
21+
22+
Once you have familiarized yourself with the dashboard and application layout templates, feel free to start editing them. For example, you will probably want to remove the "welcome" component that is rendered on your application dashboard. To do so, you may delete it from your dashboard template. Next, you're free to write the HTML needed to build your application. Remember, Jetstream uses the powerful Tailwind CSS framework, so be sure to learn more about Tailwind by consulting the [Tailwind documentation](https://tailwindcss.com/docs).
23+
24+
### Adding Additional Pages
25+
26+
By default, Jetstream's top navigation menu includes a link to the application dashboard. Of course, you are free to edit this navigation menu to add links to other pages that will be available within your application. When using Livewire, the navigation menu is defined by the `resources/views/navigation-menu.blade.php` Blade template. When using Inertia, the navigation menu is defined within the `resources/js/Layouts/AppLayout.vue` component.
27+
28+
## User Profile
29+
30+
When building a Jetstream application, it's likely that you will need to add your own forms and panels to the user profile management screen. By default, the user's profile screen contains panels to update the user's contact information, password, manage their two-factor authentication settings, and more. However, you're free to add your own additional panels to this page. To do so, you may simply edit the templates that define the page.
31+
32+
When using Livewire, the user's profile management screen is defined by the `resources/views/profile/show.blade.php` Blade template. When using Inertia, this screen is rendered by the `resources/js/Pages/Profile/Show.vue` component. To add additional panels or forms to the user profile, you may simply edit these templates as necessary for your application.
33+
34+
## Team Management
35+
36+
You may also need to add additional forms and panels to the team management screens rendered by Jetstream. These include the "team settings" screen for managing existing teams as well as the "create team" screen that is rendered when a user is creating a new team.
37+
38+
### Create Team Screen
39+
40+
When team support is enabled, Jetstream includes a screen that allows users to create new teams. You are free to add additional form fields to the form contained within this screen. Any additional form fields you add will be passed into Jetstream's `App\Actions\Jetstream\CreateTeam` action via the `$input` argument.
41+
42+
When using Livewire, the team creation screen is defined by the `resources/views/teams/create.blade.php` Blade template. When using Inertia, this screen is rendered by the `resources/js/Pages/Teams/Create.vue` component.
43+
44+
### Team Settings Screen
45+
46+
When team support is enabled, Jetstream includes a screen that allows users to manage the settings for their existing teams, such as changing the team name or inviting additional team members. You're free to add your own additional panels to these pages. To do so, you may simply edit the templates that define the page.
47+
48+
When using Livewire, the team settings screen is defined by the `resources/views/teams/show.blade.php` Blade template. When using Inertia, this screen is rendered by the `resources/js/Pages/Teams/Show.vue` component.
49+
50+
## Banner Alerts
51+
52+
Jetstream includes a notification banner which can be displayed at the top of your application's UI.
53+
54+
If you are using the Livewire stack, your application will contain the banner component at `resources/views/components/banner.blade.php`. If you are using the Inertia stack, your banner component will be contained within the `resources/js/Components/Banner.vue` Vue component.
55+
56+
To instruct Jetstream to display the banner, you must flash a `flash.banner` message to the session. In addition to the banner message, you may also instruct Jetstream to display the banner with a `success` style or a `danger` style:
57+
58+
```php
59+
$request->session()->flash('flash.banner', 'Yay it works!');
60+
$request->session()->flash('flash.bannerStyle', 'success');
61+
62+
return redirect('/');
63+
```
64+
65+
You may also instruct Jetstream to display the banner by invoking the `banner` or `dangerBanner` methods on a redirect response instance:
66+
67+
```php
68+
return redirect()->route('subscriptions')->banner('Subscription created successfully.');
69+
70+
return redirect()->route('subscriptions')->dangerBanner('Subscription cancellation failed.');
71+
```

Diff for: 3.x/concept-overview.md

+64
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
# Concept Overview
2+
3+
[[toc]]
4+
5+
## Introduction
6+
7+
Laravel Jetstream's architecture is a little different from other Laravel application starter kits such as [Laravel Breeze](https://laravel.com/docs/starter-kits). In this documentation, we'll cover some of the high-level concepts that will help you understand how Laravel Jetstream is constructed.
8+
9+
## Laravel Fortify
10+
11+
Under the hood, the authentication portions of Jetstream are powered by [Laravel Fortify](https://github.com/laravel/fortify), which is a front-end agnostic, "headless" authentication backend for Laravel.
12+
13+
Fortify registers the routes and controllers needed to implement all of Laravel's authentication features, including login, registration, password reset, email verification, and more. After installing Fortify, you may run the `route:list` Artisan command to see the routes that Fortify has registered.
14+
15+
Since Fortify does not provide its own user interface, it is meant to be paired with your own user interface which makes requests to the routes it registers. Laravel Jetstream is our first-party implementation of a user interface built on top of the Fortify authentication backend.
16+
17+
#### Fortify Configuration
18+
19+
When Jetstream is installed, a `config/fortify.php` configuration file is installed into your application. Within this configuration file, you can customize various aspects of Fortify's behavior, such as the authentication guard that should be used, where users should be redirected after authentication, and more.
20+
21+
Within the `fortify` configuration file, you can also disable entire features of Fortify, such as the ability to update profile information or passwords.
22+
23+
## Actions
24+
25+
In contrast to [Laravel Breeze](https://laravel.com/docs/starter-kits), Laravel Jetstream does not publish controllers or routes to your application. Instead, Jetstream's functionality is customized via "Action" classes. During the Jetstream installation process, actions are published to your application's `app/Actions` directory.
26+
27+
Action classes typically perform a single action and correspond to a single Jetstream or Fortify feature, such as creating a team or deleting a user. You are free to customize these classes if you would like to tweak the backend behavior of Jetstream. Each of the relevant actions published by Jetstream will be discussed within the feature's corresponding documentation.
28+
29+
## Views / Pages
30+
31+
During installation, Jetstream will publish a variety of views and classes to your application. When using Livewire, views will be published to your application's `resources/views` directory. When using Inertia, "Pages" will be published to your `resources/js/Pages` directory.
32+
33+
The views / pages published by Jetstream contain every feature supported by Jetstream and you are free to customize them as needed. Think of Jetstream as a starting point for your application. Once you have installed Jetstream, you are free to customize anything you like.
34+
35+
### Layouts
36+
37+
#### The Application Layout
38+
39+
After installation, your Jetstream application will contain two "layouts". First, Jetstream creates an application layout that is used to define the layout of your application's pages that require authentication, such as your application's dashboard. When using the Livewire stack, this layout is defined at `resources/views/layouts/app.blade.php` and rendered by the `App\View\Components\AppLayout` class. When using the Inertia stack, this layout is defined at `resources/js/Layouts/AppLayout.vue`.
40+
41+
#### The Livewire Guest / Authentication Layout
42+
43+
In addition to the application layout, Jetstream creates a "guest" layout that is used to define the layout for Jetstream's authentication-related pages, such as your application's login, registration, and password reset pages. When using the Livewire stack, this layout is defined at `resources/views/layouts/guest.blade.php` and rendered by the `App\View\Components\GuestLayout` class.
44+
45+
### Dashboard
46+
47+
The "main" view of your application is published at `resources/views/dashboard.blade.php` when using Livewire and `resources/js/Pages/Dashboard.vue` when using Inertia. You are free to use this as a starting point for building the primary "dashboard" of your application.
48+
49+
## Tailwind
50+
51+
During installation, Jetstream will scaffold your application's integration with the Tailwind CSS framework. Specifically, a `postcss.config.js` file and `tailwind.config.js` file will be created. These two files are used to build your application's compiled CSS output. You are free to modify these files as needed for your application.
52+
53+
In addition, your `tailwind.config.js` file has been pre-configured to support PurgeCSS with the relevant directories properly specified depending on your chosen Jetstream stack.
54+
55+
Your application's `package.json` file is already scaffolded with NPM commands that you may use to compile your assets. For more information on compiling your application's assets, consult the [Vite documentation](https://laravel.com/docs/vite):
56+
57+
```bash
58+
# Compile your CSS / JavaScript for development and recompile on change...
59+
npm run dev
60+
61+
# Compile your CSS / JavaScript for production...
62+
npm run build
63+
```
64+

Diff for: 3.x/features/README.md

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
<meta http-equiv="refresh" content="0;url=/2.x/features/api.html" />

Diff for: 3.x/features/api.md

+71
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
# API
2+
3+
[[toc]]
4+
5+
## Introduction
6+
7+
Jetstream includes first-party integration with [Laravel Sanctum](https://laravel.com/docs/sanctum). Laravel Sanctum provides a featherweight authentication system for SPAs (single page applications), mobile applications, and simple, token-based APIs. Sanctum allows each user of your application to generate multiple API tokens for their account. These tokens may be granted abilities / permissions which specify which actions the tokens are allowed to perform.
8+
9+
![Screenshot of Laravel Jetstream API](./../../assets/img/api.png)
10+
11+
By default, the API token creation panel may be accessed using the "API" link of the top-right user profile dropdown menu. From this screen, users may create Sanctum API tokens that have various permissions.
12+
13+
:::tip Sanctum Documentation
14+
15+
For more information on Sanctum and to learn how to issue requests to a Sanctum authenticated API, please consult the official [Sanctum documentation](https://laravel.com/docs/sanctum).
16+
:::
17+
18+
## Enabling API Support
19+
20+
If your application will be offering an API that may be consumed by third-parties, you must enable Jetstream's API feature. To do so, you should uncomment the relevant entry in the `features` configuration option of your application's `config/jetstream.php` configuration file:
21+
22+
```php
23+
'features' => [
24+
Features::profilePhotos(),
25+
Features::api(),
26+
Features::teams(),
27+
],
28+
```
29+
30+
## Defining Permissions
31+
32+
The permissions available to API tokens are defined using the `Jetstream::permissions` method within your application's `App\Providers\JetstreamServiceProvider` class. Permissions are defined as simple strings. Once they have been defined they may be assigned to an API token:
33+
34+
```php
35+
Jetstream::defaultApiTokenPermissions(['read']);
36+
37+
Jetstream::permissions([
38+
'post:create',
39+
'post:read',
40+
'post:update',
41+
'post:delete',
42+
]);
43+
```
44+
45+
The `defaultApiTokenPermissions` method in the example above may be used to specify which permissions should be selected by default when creating a new API token. Of course, a user may uncheck a default permission before creating the token.
46+
47+
## Authorizing Incoming Requests
48+
49+
Every request made to your Jetstream application, even to authenticated routes within your `routes/web.php` file, will be associated with a Sanctum token object. You may determine if the associated token has a given permission using the `tokenCan` method provided by the `Laravel\Sanctum\HasApiTokens` trait.
50+
51+
This `HasApiTokens` trait is automatically applied to your application's `App\Models\User` model during Jetstream's installation. Typically, you will call the `tokenCan` method within your application's controllers, Livewire components, or [authorization policies](https://laravel.com/docs/authorization#creating-policies):
52+
53+
```php
54+
return $request->user()->id === $post->user_id &&
55+
$request->user()->tokenCan('post:update')
56+
```
57+
58+
### First-Party UI Initiated Requests
59+
60+
When a user makes a request to a route within your `routes/web.php` file, the request will typically be authenticated by Sanctum through an authenticated session cookie based guard. In most Laravel applications, this is the `web` guard.
61+
62+
When the user is making a first-party request through the application UI, the `tokenCan` method will always return `true`. Remember, this does not necessarily mean that your application has to allow the user to perform the action. Typically, your policies will determine if the token has been granted permission to perform the abilities **as well as check that the user instance itself should be allowed to perform the action**.
63+
64+
For example, in the case of updating a blog post, this might mean checking that the token is authorized to update posts **and** that the post belongs to the user:
65+
66+
```php
67+
return $request->user()->id === $post->user_id &&
68+
$request->user()->tokenCan('post:update')
69+
```
70+
71+
At first, allowing the `tokenCan` method to be called and always return `true` for first-party UI-initiated requests may seem strange; however, it is convenient to be able to always assume an API token is available and can be inspected via the `tokenCan` method. This means that you may always call the `tokenCan` method within your application's authorization policies without worrying about whether the request was triggered from your application's UI or was initiated by one of your API's third-party consumers.

0 commit comments

Comments
 (0)