This episode is for members only

Sign up to access "Build a Starter Kit With Inertia and Fortify" right now.

Get started
Already a member? Sign in to continue
14. Client-side feature management


Your progress
  • Total: 5h 21m
  • Played: 0m
  • Remaining: 5h 21m
Join or sign in to track your progress


OK, so now that we know how enabling and disabling of features works within Fortify,
let's go ahead and disable registration again and then see how we can toggle this on the client side. We know that if we disable registration, as an example, we can't see this modal and obviously we can't submit that data through. So just before we do that, let's go over and add a kind of feature flag to this. So I'm going to go over to handle inertia request because we're going to
want this globally within our application to decide whether to show stuff on the client or not. And let's just mock this out really quickly. We're going to end up with a much better solution in a moment. So let's just call this features and then say registration. And with this, what we can do is use that features class to actually give a boolean value in here. So we saw that used over
in our routes and web and we can just take this line here and we could just pop this in here and of course import features. So that's going to give us a global way to decide whether to show stuff on the client if registration is enabled or disabled. So let's go ahead and try this out and then we'll go ahead and refactor this. So let's go over to our navigation and we'll find
create an account. And really simply, we could just add a check on here. So page props features and registration. And if that's disabled, it's not going to show anything. We can do the same thing for the mobile version of this as well. Just down here. There we go. So it's enabled at the moment. Let's go ahead and disable this under our fortify config. And sure enough, that disappears.
So we can't click it. Obviously, the route is not found because we've added that on the back end as well. And that is our feature completely inaccessible now. Now this is fine, but it's a little bit of effort to have to go ahead and add this in here for every single feature. As we implement every feature, we're going to be adding the check, the necessary check to make sure
we show stuff on the client side and also disable any routes. But it's going to be really annoying to have to go through and add each of these in here and it's going to look a little bit messy. So let's go ahead and refactor this so we can make this a little bit more dynamic. And so we don't have to keep updating it every time we add in a new feature check.
So what could we do here instead? Well, let's think about the feature list that we have. So if we come over to config and fortify, we could access this entire list of features. So let's go ahead and do that first of all. And let's just die dump on this up here. So we'll create our features variable and we'll just die dump on that so we can
kind of see this as we work. So we can access our fortify config using fortify dot features. And let's dump on this and see what we get. I'm just going to make that an empty string. And there we go. So these are all of the features that are currently enabled. Now, if we go up here, we could collect these up. So create a Laravel collection from these.
And then we could map through them, check if each one is enabled, and then create a key value pair for each of these. That means that if we disable a feature, this will automatically update this array of data and it will be either true or false. So let's go ahead and map through these with keys so we get the keys and we can actually add these in. And let's go ahead and create our
closure just inside of here. Inside of this closure, we're going to get the key for each of these. So, for example, if we just returned an array here with key and true. So now if we head over to the browser and check this out, you can see that each of these are true. Now, this might be a little confusing, but we're actually going to leave this as true. And the reason being is
if, for example, we go ahead and disable one of these, it's just going to get rid of it. So let's go over to Fortify. We'll enable registration. And that's now been added to this. So we're not really going to have a true or a false value for each of these. We're just going to get rid of them. There are other ways to do this, but I think just showing the features
in here that are enabled and just having a default of true is absolutely fine in here. Okay, so now that we've done that, we can kind of refactor this down because it's actually pretty straightforward to an inline short function. So let's go ahead and just do that and bring in that key. And then we can just take this and we can go and put that directly into here. So now what we
can do is use that to check whether this is enabled or not. And now that we've done this, we can head over to our navigation. And let's just dump this out somewhere on the page. So let's say page props and features. And we can see that we've got these keys in here. Now, what we can do with that is just do exactly what we're already doing here. So if we come over to create an account, we can
access this. If we're trying to access something that doesn't exist, we're not going to see an error. It's just not going to do anything. So we'll just get a null value back there. So we can still access these like this. So this is now just going to work. If we go over to config and fortify and we disable registration, that's now disabled obviously on the back end. And it's also disabled
on the client side as well. Now, we're going to tweak this a little bit later because we're going to have certain batches or groups of things that are enabled like security. And we might not want to show entire sections based on certain features that are enabled. But for now, that's pretty much it. Now, obviously, I'm going to go ahead and re-enable registration. But now we've got
an up-to-date list of all of the features that Fortify could have. And we are reflecting that on the client side and, of course, on the back end as well. So we'll add these as we go. But that is pretty much it. We've got a client-side solution and a back-end solution for checking and disabling features if they're not enabled in our config.
40 episodes5 hrs 21 mins


Let’s build our own Laravel starter kit with Inertia and include all the features you’d expect. We’ll implement authentication, email verification, profile photo uploads, two factor authentication, and more.

Fortify is a frontend agnostic authentication package for Laravel, meaning most of the work is done for us — we just need to build the frontend and make requests to the endpoints that Fortify registers.

Once you’re done, you’ll have a clean slate for building your next project, with the ability to control everything in your own starter kit.

Alex Garrett-Smith
Alex Garrett-Smith
Hey, I'm the founder of Codecourse!


No comments, yet. Be the first to leave a comment.