Hi n2zb! You can preload pivot table data two ways.

First option is to define them directly in the relationship definition, as shown in this lesson at 6:50. This will always include them when the relationship is preloaded. So, this is a great option is you'll frequently need that pivot data.

export default class Movie extends BaseModel {
  // ...

  @manyToMany(() => Cineast, {
    pivotTable: 'cast_movies',
    pivotTimestamps: true,
    pivotColumns: ['character_name', 'sort_order'], // 👈
  })
  declare castMembers: ManyToMany<typeof Cineast>

  // ...
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

The second option is to add them on a per-query basis, as needed.

const crew = await movie
  .related('crewMembers')
  .query()
  .pivotColumns(['title', 'sort_order']) // 👈
  .orderBy('pivot_sort_order')

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

This will then add those pivot columns into the $extras object of the preloaded relationship.

const crewMember = {
  // ...

  '$extras': {
    pivot_title: 'Art Director', // 👈
    pivot_sort_order: 0, // 👈
    pivot_movie_id: 417,
    pivot_cineast_id: 40,
    pivot_created_at: DateTime { ts: 2024-03-30T11:59:58.911+00:00, zone: UTC, locale: en-US },
    pivot_updated_at: DateTime { ts: 2024-03-30T11:59:58.911+00:00, zone: UTC, locale: en-US }
  },
}

Note that the column names are prefixed with pivot_ and that the ids of the relationship are always included. Also note, if you're serializing your models, you'll want to turn on extras serialization via the below on the model, and they'll be serialized as meta.

export default class Cineast extends BaseModel {
  serializeExtras = true

  // ...
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

We get into all of this in various later lessons in this series as well, if you'd like a deeper dive!

Hi codthing! Everything you've shared looks right. If you're viewing your Redis database with a GUI application, those often don't reflect live data and require refreshing in order for them to reflect changes made to the database contents. Also, make sure you're viewing the Redis database actually being used by your application! This can be found within config/redis.ts

const redisConfig = defineConfig({
  connection: 'main',

  connections: {
    main: {
      host: env.get('REDIS_HOST'),
      port: env.get('REDIS_PORT'),
      password: env.get('REDIS_PASSWORD', ''),
      db: 1, // 👈 indicates I'm using Redis DB1, DB0 is typically the default
      keyPrefix: '',
      retryStrategy(times) {
        return times > 10 ? null : times * 50
      },
    },
  },
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  
config
redis.ts

You might also do a sanity check, just to ensure your controller methods are actually being hit correctly, by adding a console log to each.

//redis controller
export default class RedisController {
    public async destroy({ response, params }: HttpContext) {
        console.log('destroy', params.slug)
        await cache.delete(params.slug)
        return response.redirect().back()
    }

    public async flush({ response }: HttpContext) {
        console.log('flushing redis')
        await cache.flushDb()
        return response.redirect().back()
    }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

If neither of those help, please feel free to share a link to your repository and I can take a deeper look to see if anything stands out!

Anytime! Okay cool, yeah updating the logger destination and logging the queries, as shown in the last two code blocks in my comment above, should get that working for ya!

Hi Rajeeb!

Console logging a call to toSQL() as you have should work, you should be seeing something like the below in your console.

However, there is a nicer way to do this, using pretty printed query logging. Within your config/database.ts, set prettyPrintDebugQueries: true.

const dbConfig = defineConfig({
  prettyPrintDebugQueries: true, // 👈
  connection: 'postgres',
  connections: {
    postgres: {
      client: 'pg',
      connection: {
        host: env.get('DB_HOST'),
        port: env.get('DB_PORT'),
        user: env.get('DB_USER'),
        password: env.get('DB_PASSWORD'),
        database: env.get('DB_DATABASE'),
      },
      migrations: {
        naturalSort: true,
        paths: ['database/migrations'],
      },
    },
  },
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  
config
database.ts

Then, you can either globally enable query logging, by adding a debug: true to your driver object.

const dbConfig = defineConfig({
  prettyPrintDebugQueries: true,
  connection: 'postgres',
  connections: {
    postgres: {
      debug: true, // 👈
      client: 'pg',
      connection: {
        host: env.get('DB_HOST'),
        port: env.get('DB_PORT'),
        user: env.get('DB_USER'),
        password: env.get('DB_PASSWORD'),
        database: env.get('DB_DATABASE'),
      },
      migrations: {
        naturalSort: true,
        paths: ['database/migrations'],
      },
    },
  },
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  
config
database.ts

Or, you can enable this this on a per-query basis by adding debug(true) to the query.

await Collection.query().where('slug', params.slug).debug(true).firstOrFail()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

With that set, you should see something like below in your console

Now, unfortunately, this pretty print can't be logged to a file. You can still log the query to a file though. Within your config/logger, set the non-production logger target to a file at the destination you'd like. If that's a file in storage, it'd look something like:

const loggerConfig = defineConfig({
  default: 'app',

  loggers: {
    app: {
      enabled: true,
      name: env.get('APP_NAME'),
      level: env.get('LOG_LEVEL'),
      transport: {
        targets: targets()
          // 👇
          .pushIf(!app.inProduction, targets.file({ destination: './storage/local.log' }))
          .pushIf(app.inProduction, targets.file({ destination: 1 }))
          .toArray(),
      },
    },
  },
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  
config
logger.ts

Then, add a global listener for the query within a preload.

node ace make:preload events

import emitter from '@adonisjs/core/services/emitter'
import logger from '@adonisjs/core/services/logger'

emitter.on('db:query', function (query) {
  logger.debug(query)
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  
start
events.ts

With this all your logs, including queries, will be written to the file at the location you've specified! Hope this helps!! 😊

That's awesome to hear, Vladimir! I'm really happy to hear you're finding the lessons early to follow and enjoying them, thank you for sharing!

Anytime! Awesome, I'm happy to hear that got things working for you, memsbdm!!

Hey memsbdm! Yeah, the deployed app has been expanded beyond the scope of the Building with AdonisJS & Inertia series. It's what I use to plan lessons and series, and also feeds the data shown on our schedule page. So, I've added some things since. Apologies if that caused any confusion!

I did have the repository private, but just made it public. You can find the code for the live PlotMyCourse app here.

The <Sortable> component accepts a tag prop, and I have that set as tbody so that it plays well structurally with the table itself. I think that might be all you're missing!

<Table>
  <TableHeader>
    <TableRow>
      <!-- ... -->
    </TableRow>
  </TableHeader>
  <Sortable
    v-if="courses?.length"
    v-model="courses"
    item-key="id"
    handle=".handle"
    tag="tbody" <!-- 👈 -->
    class="[&_tr:last-child]:border-0"
    @end="onOrderUpdate"
  >
    <template #item="{ element: course }">
      <TableRow class="group">
        <!-- ... -->
      </TableRow>
    </template>
  </Sortable>
</Table>

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Anytime, Nidomiro!! 😊

Awesome, that's great to hear!
Anytime!!

Hi memsbdm!

It looks like this was a tiny change that occurred between InertiaJS v1 and v2! In this lesson, I'm still working with Inertia v1, which is why everything works without issue for me. We upgrade to InertiaJS v2 in module 13, though this is one change I missed!

Here's what the FormDataType looks like in InertiaJS v1:

And then here is what it is now in InertiaJS v2:

So, your solution is perfect for v2! You could probably try and use `Record<string, FormDataConvertible> if you'd prefer to be as accurate as possible! Though I don't believe what you have should cause any issues down the road! Thank you for sharing! 😊

Anytime and no worries at all! That's completely understandable!! 😊

Hi Nidomiro!

Yep, that's absolutely a valid approach with AdonisJS! I haven't done it myself, but you can check out Romain Lanz's website which uses this setup. He is one of the AdonisJS Core Members.

You'd need to move some files around to your liking manually, then update the imports within your package.json to match your feature names (if you want to use import aliases) rather than having one for controllers, models, etc.

Hi Thiago!

Sorry you're having issues! I think I found the culprit. It looks like TailwindCSS was having difficulty picking up the default configuration to use. Explicitly defining the config seems to have fixed the issue - at least on my end, but I couldn't get the error to consistently happen.

Please let me know if this remedied the issue for you!

Thanks and sorry again you're having issues!

Sure thing, Aaron!!

Hi Tigerwolf!

Lucid cascades the transaction to relationship operations for us! So, when we attach the transaction to the operation that creates the organization, the transaction reference will be kept in the organization instance.

return db.transaction(async (trx) => {
  const organization = await Organization.create(data, { client: trx })
  
  organization.$trx // 👈 holds the transaction

  // ...
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

This transaction reference is then automatically used when we perform subsequent operations with this organization, which includes related operations.

return db.transaction(async (trx) => {
  const organization = await Organization.create(data, { client: trx })
  
  // 👇 passes $trx on the organization along with the attach db operation
  return organization.related('users').attach({
    [user.id]: {
      role_id: Roles.ADMIN,
    },
  })

  // ...
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

The managed transaction, then, wraps the callback within a try/catch block. The transaction is committed if the callback completes and no errors are thrown. Otherwise, if an error is caught, the transaction is rolled back. Essentially doing the below for us in a nicer syntax.

const trx = await db.transaction()

try {
  const organization = await Organization.create(data, { client: trx })
  
  // 👇 passes $trx on the organization along with the attach db operation
  return organization.related('users').attach({
    [user.id]: {
      role_id: Roles.ADMIN,
    },
  })

  // ...

  await trx.commit()
} catch (error) {
  await trx.rollback()
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

So, as long as we don't eat the errors thrown by the operations we're performing, the managed transaction will catch it and roll back our transaction. This is regardless of how we structure our code within the managed transaction, including splitting it into additional methods.

So, to answer your question, If an issue occurs in assignAdmin or createDefaults the managed transaction will catch this and roll back our transaction for us! You can see this for yourself by trying to assign the user a role_id that doesn't exist. Since we're using a foreign key constraint here, attempting to do so will throw an error.

static async #assignAdmin(organization: Organization, user: User) {
  return organization.related('users').attach({
    [user.id]: {
      role_id: 45, //Roles.ADMIN, // 👈 replace admin with some non-existant id
    },
  })
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Anytime! Awesome, glad to hear you’re all set Oliver!

Hi Oliver!

Partial route parameters, like /fly-to-:city aren't supported by the AdonisJS Router at present. However, you can use a vague route parameter in conjunction with a route param validator to make this work.

router.get('/:flyToCity', [Controller, 'handle']).where('flyToCity', /^fly-to-/)

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

The where here is applying a validator to the route parameter, stating that the parameter should start with "fly-to-" in order for the route to match the definition.

We have a lesson where we cover this using user profiles in our Let's Learn AdonisJS 6 series if you'd like to learn more!

Awesome, I'm really happy to hear you're all set up now! Thanks a bunch, Ikeh!! 😊

Alrighty, so I took a look into it. I was also getting the error with MySQL, and it was indeed a code issue! I accidentally missed binding the organization to the transaction, which caused the decrement to run outside the confinement of the transaction - hence the lock block.

Below is the updated code that fixes this issue! Terribly sorry about the miss here! I'll get a note about this added into the lesson.

export default class DestroyLesson {
  static async handle({ organization, id }: Params) {
    const lesson = await organization.related('lessons').query().where({ id }).firstOrFail()

    await db.transaction(async (trx) => {
      lesson.useTransaction(trx)
      organization.useTransaction(trx) // 👈

      await lesson.delete()
      await organization
        .related('lessons')
        .query()
        .where('moduleId', lesson.moduleId)
        .where('order', '>', lesson.order)
        .decrement('order')
    })

    return lesson
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hi Deniz!

I think you've got a small typo. You're flashing to notification in your controller, but sharing notifications. You'll want those two to match 1:1.

Also, make sure you've got the flash message key notification or notifications (whichever you pick) defined as a prop on your page/layout. Otherwise Vue, for example, won't ingest it and will treat it as an attribute and not a prop.

Anytime! Awesome, I'm glad to hear you were able to get it fixed up! As a morning person, I can concur! 😄

No worries at all! It's been a long while since I've used MySQL, so my platform-specific knowledge here will be limited. But, if it works fine without the decrement then I'd imagine you most likely have a stuck lock or transaction on one of your lessons. Something not directly related to the decrement, but rather blocking the decrement from succeeding.

This may or may not be code-related. It could be a lock added by a client application or CLI using your MySQL table. It could also be another transaction touching one of the lesson rows that was never committed or rolled back. Here is a StackOverflow thread that discussed some query options to dig into what might be locking things up.

I can try and get MySQL set up and test it out this evening after work to ensure it isn't a code issue specific to MySQL.

Hi Ikeh! Redis is used for a very brief period in this series. I believe 2.14 and 2.15 are the only two lessons we use it within, just to show how to work with it. It is completely skippable if you don't feel like setting it up on your machine!

Alternatively, you can use Redis Cloud. They offer a small free tier if you click "Try for Free" and then select the "Essentials" plan option during sign-up, as shown below.

Once you've created your database, you can click on "connect" and then expand the "Redis Client" section. Here you can copy/paste the username, password, host, and port into your .env file of your project.

Note: you have to click the "copy" button to get the actual password

That's awesome! I'm happy to hear you're making progress with it! I wouldn't worry too much about doing things the best or cleanest way, especially initially! So long as it works for what you need in a way you understand, that's all that matters to keep progress going. You can always refactor down the road if need be. 😊

Awesome! I'm glad to hear you were able to get it figured out! 😊

Hi Ryan!

The authenticated user isn't populated until you tell AdonisJS to populate it. This can be done using the auth middleware, silent_auth middleware, or manually calling auth.check() as needed. You're most likely missing one of those.

Note that you also need to specify a serialized type for your Lucid Models using either casting or DTOs.

Yeah, you'll want the HttpContext here to be optional. Then, when you don't have an HttpContext, you'll want to signal to yourself that your permissions haven't been populated; leaving it null there could be a way to do that.

@afterFind()
static async attachPermissions(workspace: Workspace) {
  const ctx = HttpContext.get()

  if (!ctx) return

  // ...
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

If the HttpContext isn't optional then your model would also become unusable within commands, jobs, events, and all that fun stuff. In most cases, you shouldn't need permissions on those types of requests. On the off chance you do, that's where you'd want to extract the contents of the hook into a model method, service, or action so you can also use the same logic on an as-needed basis.

Hi Aaron!

It sounds like your organization is undefined within the SortableLessons component. If it works fine within SortableModules then it should be populated on the page okay. Make sure you've got it within the props being passed into SortableLessons!

<SortableLessons
  v-model="modules[index]"
  :organization="organization" <!-- 👈 -->
  :course="course"
/>

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

If it's there, then make sure it is within SortableLessons props.

const props = defineProps<{
  organization: Organization // 👈
  course: CourseDto
  modelValue: ModuleDto
}>()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

I'd reckon it's one of those two, but if it is in both of those spots, I'd recommend using the Vue DevTools to inspect the flow of this prop to see where it might be getting lost.

Hope this helps!!

Oh shoot - I recorded these updates and got the Inertia one updated but missed this one. I'll get this updated after work!

Thanks so much for watching, cortesbr!! ❤️

Hi Emilien!

No worries at all!! 😊

Yeah, things spiral here quickly depending on your approach. It's a big enough of a topic to be a series of its own, but I'll try to give an overview below.

Access Determination

So, the first thing you need to do is figure out how the more granular access will be determined. Will only the creator have permission to edit, update, and delete? Or, maybe the creator can invite others to edit, update, and delete? Essentially, how are the different roles going to be determined at those different levels?

Creator Only

If it's just the creator, then that's much easier. You'd want to capture the userId of the user who created the resource. For example, adding a ownerId onto the Course model. Then, you'd handle the logic very similarly to how we allow org members to remove themselves throughout the next two lessons (12.1 & 12.2). By giving priority to allow the action if the ownerId matches the authenticated user's id. When that's the case, you'd want to ignore whatever the role's permission says and allow the action.

Resource Specific Invitations

If you want to allow the creator to invite/share with others to collaborate, you'll need a table to track that. This table could look many different ways.

• It could be a single table per resource, ex: course_user consisting of course_id, user_id, and role_id if there are different levels and not an on/off.

• A polymorphic table, ex: permission_user consisting of something like entity , entity_id, user_id, and again role_id if needed. Here, entity would be the table/model and entity_id would be the row's id for that table/model. Now, Lucid doesn't support polymorphic relationships but that doesn't mean you couldn't specifically query for what you need. The downside is, that you can't use foreign keys for the entity_id since it'll be dynamic

• A single table with a nullable column per resource, ex: permission_user consisting of something like course_id, another_id, user_id, and again role_id if needed. This is similar to the polymorphic relationship, but you have a specific column per resource needed. Plus here, is you can keep foreign keys. Downside here, is it can be a lot of columns if a lot of resources need to use it.

There are many different ways authorization can look beyond these two, but determining what that looks like is the first step.

Populating Permissions

When it comes to populating these permissions, again, it's going to depend on just how granular you need to go. For us in this series, things were simple so our approach was simple. The approach covered here was meant mostly for a single set of roles that then trickle down as needed.

If you're going to be listing courses and each of those courses in the list is going to have varying permissions based on invites/shares, then you might be better off moving the can approach to the row level. For example, allowing something like course.can.edit to determine if the authenticated user can edit the course. This could be done using something like model hooks.

You could also always reach for a package to help achieve your implementation.

That was a lot, sorry! Hopefully, that helps at least little though.

Sorry I couldn't be of more help, Rajeeb! I hope you're able to find a solution. You might have luck reaching out on the AdonisJS Discussions or Discord.

My pleasure, tigerwolf!! Happy to be able to help! 😊

Hello, tigerwolf!

Sorry about the inconvenience!! Thankfully, the video host we're using for these videos allows specifying custom CSS within the player's iframe, and I was able to get the captions pushed up when the video toolbar is shown. I also hid the heatmap, which seems to be mostly what was going over the subtitles.

We're in the process of switching from an actual video host to Cloudflare R2 with a hand-picked player, so hopefully we'll have more improvements in this area down the road!

Thank you very much for the feedback!!

Terribly sorry about that, tigerwolf! The subtitles for this lesson have now been corrected. Thank you very much for the heads up!

Hi Rajeeb!

Do you have ts-node-maintained installed? This package is a version the AdonisJS Core team support that's a maintained fork of ts-node.

Please make sure that this package is installed and that you're attempting to run your Ace CLI command from the correct directory. If in development, that'll be the root of your project. If you're attempting to run a built application, that'll be in the build directory. I'm unfamiliar with Docker, but that may be a source of the issue as well.

As a sanity check, I just pulled down a new installation of the AdonisJS Inertia starter kit and it installed and booted successfully.

Hi emilien!! I think your linked repo is private, but I'm happy to hear you were able to find a solution! I just took a look into it and the target was email.database.unique where email is the validator field's name.

The below, within resources/lang/en/validator.json, worked for me!

{
  "shared": {
    "messages": {
      "email.database.unique": "This is from the translation"
    }
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

You can find the logic used to find a translated message within the I18nmessagesProvider . Also, my initial thinking was incorrect. This is actually used immediately by the validator, not inside the middleware!

Hi emilien!

I actually haven't used the i18n AdonisJS package at all yet, probably should familiarize myself with it though haha.

The field target should just be email.unique, I believe. If you're trying to use the Detect User Locale middleware to automatically do this, it might be possible that the Inertia middleware is committing it's session store before the Detect User Locale middleware is able to apply the translations. Playing with the middleware order there, having inertia before the Detect User Locale inside start/kernel.ts, might help.

You could also try passing it directly into the validate method, as shown here.

When I have some free time, I'll play around with it a bit to see if I can get it figured out!

Thanks so much for sharing, cortesbr!! I believe this is either a browser or extension issue. After closely inspecting, I think the page is actually still there & active, the browser just isn't showing it to you for some reason.

You do click several places, but at 0:07 you click somewhere that actually has an anchor link. At 0:10 the site comes back and briefly shows the linked anchor that was clicked at 0:07 is "Allowing Admins to Update Movies and Clear Values". Moments later the page for that clicked lesson loads.

I've been trying for the past half hour or so to replicate this on my Windows machine using Edge, and haven't had any luck. Browsers, Edge included, have a number of battery/resource saving features like putting inactive tabs to sleep. This could be one cause - though I tested several Edge settings and couldn't replicate. Extensions are also common sources of issues.

I'll keep an eye out and try replicating further, but in the meantime I'd recommend giving it a go in a private/incognito window to see if that fixes the issue you're having. If I had to place a wager, I'd guess it's an extension.

Thanks for sharing, jals!!

Looks like npx shadcn-vue@radix is targeting 0.11.4, just as an alias, so those should behave the same. It's possible there was a network issue - their add commands send API requests out to the actual ShadCN site to get configurations, like colors. Based on this issue, you might also have an invalid baseColor in your components.json.

Here's my attempt to run it and you can see it prompted me to install v0.11.4

The unsupported engine warning you got is stating that the package undici requires NodeJS v20.18.1 or higher, but you have v20.11.0 installed. So, that'll go away if you update your NodeJS version, not entirely sure what makes use of undici.

Yep! I'm working on updating lesson 1.4 of this series this weekend just for this, though in the updated lesson, I'll recommend sticking with Radix for the time being. Getting their Reka update working is too much of a change, and there may be several inner-component changes as well that would confuse those following this series. You can still access the documentation for the Radix version at radix.chadcn-vue.com. You can also target it via their CLI via:

npx shadcn-vue@radix <command>

I've tried getting their Reka updating working myself, and tried re-initializing - neither work without compromise. They dropped support for specifying a tsconfig.json location and will instead only check the project root for a tsconfig.json, tsconfig.web.json, or tsconfig.app.json file in that order. They have a preflight check on their CLI commands that will fail the command if the found tsconfig is missing an alias definition, which is also why it states the components.json file is incorrect despite it matching their spec.

So the only possible way to get their Reka UI update working would be to rename the AdonisJS tsconfig.json file in the root of the project to something else, as Shadcn-Vue's preflight command check will only ever find and use this tsconfig file due to its name and priority in their search.

You'd then need to move your Inertia tsconfig.json file out into the project root.

I haven't tried, but you may have luck getting things working if you move all the Shadcn-Vue stuff into the inertia folder.

Hi cortesbr! I'm not sure I'm fully following. Would you mind providing a little more context, please?

For example, are you experiencing this behavior:

1. On the actual Adocasts site here at adocasts.com?

2. On a cloned Adocasts site locally on your machine?

3. As part of the code from the Let's Learn AdonisJS 6 series in the linked lesson?

Additionally, when you say the page initially appears blank - is this completely blank as in nothing at all shows, or is it just a certain section of the page? If it is just a certain section, which section would that be?

Thanks in advance!!

Anytime! Awesome, great to hear things are working for you now!
No worries at all, always happy to help where I can! 😊

Anytime, Rajeeb! Awesome, great to hear!

Hi Rajeeb! Apologies about that, it looks like Shadcn-Vue changed their init command to require more manual work to get things set up. Please try initializing using the latest 0 version with:

npx shadcn-vue@0 init

I'll have to compare to see what/why they changed it, and I will update this lesson accordingly!

—

Edit: Okay, so it looks like in v1 they've switched the default core library from using Radix-Vue to Reka-UI. Using the below to initialize your Shadcn-Vue installation is now the recommended command to continue using Radix, which is what this series uses.

npx shadcn-vue@radix init

With this command, this installation should match that covered in this lesson. I'll get this lesson updated accordingly.

Hi n2zb!

I have never tried changing the table property at runtime like you're asking about. I imagine it would work, but even if it does, it would be susceptible to accidentally entering data into the wrong table.

Instead, I'd recommend defining those shared columns & relationships via a Model Mixin and then composing the mixin into a separate model per table. I thought I had a free lesson on this, but it looks like there is currently only this one from the Building with AdonisJS & Inertia series. I'll have to make a free one on this as well, as it's quite handy.

In the meantime, you can get the gist of it via the code from this series.

• With Organization Model Mixin that defines an organizationId and relationship

• Composing the mixin into a model

I'm not getting that exact error, but I see a couple of issues that'll cause things not to work correctly.

First, for your form errors, you want to use $messages not $message

<label>
  <span> Full Name </span>
  <input type="text" name="fullName" value="{{ old('fullName') || '' }}" />
  @inputError('fullName')
    {{ $messages.join(', ') }} {{-- 👈 use $messages --}}
  @end
</label>

Second, your full name input has the name fullName with a capital N while your validator has fullname, these need to match 1:1. With those mismatched and the field required by your validator, you'll always get a validation error on submission.

export const registerValidator = vine.compile(
  vine.object({
    fullName: vine.string().maxLength(100), // 👈 use fullName
    email: vine.string().email().normalizeEmail(),
    password: vine.string().minLength(8),
  })
)

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hope this helps! If, after these fixes, you're still getting the state error, please let me know which page and operation you're performing that's causing that error.

Oh nice! Yeah, this looks spot on, nicely done emilien! Thank you, I really appreciate that offer! I'm happy to hear that going through this was fruitful!! 😃

Yeah, I should probably add a note in this video for that. npx tailwindcss init -p is a TailwindCSS 3 command. TailwindCSS 4's default installation doesn't include a tailwind.config.js file anymore and comes with its own Vite plugin for simplified configuration.

Hi Aaron! Unfortunately, not out of the box. Looks like there is a community package to add support for it, though. An alternative approach I've seen discussed is to have a soft_deletes table that contains a serialized version of the deleted row with additional columns specifying its original table & id. You'd then delete the record, serialize it, then add it to the soft_deletes table so that you can still grab it and restore it if needed. I've never attempted this approach, but it does sound interesting, so I thought I'd share. Not sure how this would handle foreign keys pointing to the deleted id though.

Yes, sorry about that, those should be optional props!

Hi Nathan! Huh - yeah it sure does. 🤔

Oh snap, looks like I disabled Prettier formatting on save for TypeScript files at some point. So, Prettier just isn't running for me unless I paste or explicitly format, sorry about that! Your solution does look to be the recommended approach. I'm going to have to re-enable Prettier and add that myself. Thank you for sharing!!

Yeah, we'll add a fix for this at the end of lesson 13.0! 😊 Thanks again, jals!!

Awesome, glad to hear that helped clear things up! Ah, please don't feel dumb about that, it is just a small oversight. We've all done a lot worse!! 😊

That sounds like a great plan! Having a document/diagram of how things work would definitely help. That's something I'd like to make a more concerted effort to do in-lesson.

Anytime emilien!! Always happy to help where I can! 😊

Hi jals! That's a great point and a use-case that slipped my mind, thanks for catching that!

Adding the organizationId into the route parameters is definitely a great option. If you add the organizationId into the URL though, I might prefer to do that across the board and drop the active_organization cookie altogether. That way you only have one source of truth on which organization is being worked with. Minimizing potential confusion down the road.

You could, alternatively, use a Broadcast Channel to communicate across the tabs to notify the others when the organizationId has changed. You could then display a modal warning the user, offering to re-up their active org. You could also add an event when the tab is focused to update, set, or check the active organizationId. Something like the below would probably suffice.

onMounted(() => window.addEventListener('focus', onFocus))
onUnmounted(() => window.removeEventListener('focus', onFocus))

function onFocus() {
  router.get(`/organizations/${props.organization.id}`)
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Alrighty, I think I see what's going on! Where your project differs is that your /workspaces/:id route merely renders a page. In our project, and even in your main branch, this instead sets the active org/workspace in our PlotMyCourse & on your main branch, then redirects back to the dashboard.

Where I think the confusion comes in is the /:id in your /workspaces/:id route is merely symbolic since you're actually loading the workspace via the user's cookie. So, the displayed workspace is whatever is stored in the cookie and not what is provided via the route parameter id. Things do seem to still be working, the issue is that the id in the url can differ from what is actually displayed. Which, can lead to issues if you were to ever actually use the url's id for something.

So, to prevent that possibility, I would either

1. Stick to the cookie and get rid of the /:id in your /workspaces/:id route to instead have something like: /workspace or /workspaces/show

2. Or, drop the cookie and instead use the id route parameter.

To add, there isn't an issue with using /workspaces/:id/active to set the active workspace. The issue is that the new /workspaces/:id route that shows the workspace has two spots it could pull the id from; the id route parameter in the url and the cookie, and those can differ from one another.

Here's a video walkthrough of the behavior I was seeing on your feat/workspace-roles branch. This shows how user-a could request workspace b via /workspaces/2 but actually still saw workspace a; meaning the id in the url did not match the workspace used.

Here's another walkthrough of the behavior I saw on your main branch. In this branch everything works fine.

Hope this helps!!

Hi usources!

Yeah, what you're doing there is perfectly valid, and what I do in most cases where I don't need to omit a ton of fields. Alternatively, you could use an omit utility, like what is offered from Lodash, but what you have is absolutely fine!

Hi emilien! I think I'm following correctly, but let me know if this sounds off base.

So, we manage this with our organizations by querying the active org through the authenticated user, which ensures the user is a member of the org. If the user sets an id of an org that they aren't a member of, our query won't find a match and will instead overwrite the user's active org to the first org found that they're a member of.

For our application, the active organization is determined via a cookie. It sounds like you might have this set up as a route parameter.

If that's the case, ensure you attempt to query the workspace through the authenticated user. If a workspace is not found, you'll want to either:

1. Throw an unauthorized exception to prevent the user from working with the workspace. You can then offer some button to take them back to safety.

2. Or, find a valid workspace for the user and redirect them to it. You'll also want to notify them that they did not have access to the previously requested workspace.

The first option there probably being the best as it will ensure the user knows what happened. You don't want to continue onward as the URL contains an invalid id for the user, which could accidentally be used to load something or on subsequent requests sent from whatever page is rendered as a result.

Hopefully that's at least a little on point and helps a little. If not, please feel free to share your query/flow, or a representation of it, and I can try and see if anything stands out.

Hi usources! Apologies about that, and thanks so much for letting me know! Should be fixed up now! 😊

Awesome, happy to hear you were able to get it working! Anytime!

I have a few lessons on pagination (linked below), but nothing to that extent at present, unfortunately. I debated on whether to include a table with pagination, sorting, and filtering in this series but opted against it due to the series already being lengthy. I'm thinking I might do that as an aside series though.

• How to paginate filtered query results

• Persist filters easily with Lucid's query string method

• Paginated Admin Movie Table

Hi Pavlo! In Inertia, the built-in layout layer is positioned above the page component. This means that the instance of the layout component persists across page changes, as long as the page is linked to using Inertia’s Link component.

Since we're using the built-in layout layer in Inertia & our ToastManager lives within our AppLayout and AuthLayout, we're achieving exactly that. The only exception would be if we switch between those layouts - in which case you could use nested layouts to resolve that if needed.

My pleasure, Nicolas!! 😊

Anytime! Awesome, that's a perfect solution!! 😊

Hi Nicolas! Thank you so much for your kind words!

Funny enough, we'll be following this series up by adding an API to it. It'll be a quicker series than this one, and we won't be adding all the features via API, but we'll structure it as though we were.

I personally would stick to actions, services would be a like alternative, because it provides a single location for our operations to live. It allows us to minimize operational duplication between the web & API layers, which in turn simplifies any refactoring needs down the road.

As for the routes, with this application in mind, yes I would duplicate those so that we have a route definition specific to the web & API layer. For the web layer, it is unlikely to ever need to do versioning as everything can be updated at the same time. The API layer, however, would likely need versioning so we don't randomly break the clients using the API with changes, with the assumption they won't be updated along with the API itself. Additionally, the middleware between these two are likely to be different and our API layer may need to be more complex with filtering and the like. Because of those things, I would also have separate controllers for the API layer as well.

However, if none of the above are issues for an API you're building then you don't need to do that. You can instead use a single route definition for both with a single controller that uses content negotiation to determine whether the client needs an API or a Web/Inertia response. You can always separate the routes/controllers between the web and API down the road. The approach there will vary depending on the project your building and its requirements.

Hope this helps!

Yeah, if I'm following correctly, you could probably achieve that with nested whereHas calls. This builds out WHERE EXISTS SQL clauses to query based on a relationship's existence.

const user = auth.use('web').user!
const organization = await Organization
  .query()
  .whereHas('users', (users) => users
    .where('users.id', user.id)
    .whereHas('setting', (setting => setting
      .where('name', 'default organization')
      .whereRaw('settings_id = organizations.id') // use db names in whereRaw
    )
  )
  .first()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

If I'm thinking about this correctly, this would query the first organization where the id matches that of the authenticated user's user_settings.settings_id and the matched user_settings.name is also default organization.

Alternatively, you could query for the user_settings id first, then use that to query the organization.

let organization: Organization
const user = auth.use('web').user!
const defaultOrganization = await user
  .related('setting')
  .query()
  .where('name', 'default organization')
  .select('settingsId')
  .first()

if (defaultOrganization) {
  organization = await user
    .related('organizations')
    .query()
    .where('id', defaultOrganization.settingsId)
    .first()
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hi n2zb! Yeah, absolutely! I haven't done it myself, but it is definitely possible. AdonisJS is still using NodeJS at the end of the day, so you could use Firebase's NodeJS SDK so long as it works with NodeJS v20 or later & supports ESM.

Now - it won't work out of the box with a few AdonisJS packages that rely on Lucid, like:

• Auth - though it can be configured with a custom guard

• Bouncer

• Limiter - though it'd work with Redis

• Likely others

Hi cortesbr! You shouldn't need to call toObject() to access the model's properties; you should be able to directly reference them via movie.id, for example. Please make sure you're using at least NodeJS v20. If you are using NodeJS v20 or later, please feel free to share your repository and I can see if anything stands out.

The second argument of the route method is where we'd add route parameters! So, if you need a route for:

router.post('/movies/:id/activate', [MoviesController, 'activate']).as('movies.activate')

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

You could use the route method in EdgeJS to generate it like so:

<a href="{{ route('movies.activate', { id: 1 }) }}">
  Activate
</a>

The third argument is then additional config options, which includes qs to add to the URLs query string. So, there are other options you can include beyond qs to the third argument. Alternatives to this would include, as you've discovered, hard coding the query string outside the route method. You could also use the Route Builder, I believe you'd need to add this as a global to EdgeJS as I don't think it is included out of the box. However, the Route Builder would be AdonisJS solution to your second example!

What I normally do, though, is wrap the route helper in my own service to make things super easy to read! For example, a usage of my form service would be:

<form method="POST" action="{{ form.delete('redis.flush') }}">
</form>

You could also create EdgeJS components for this as well, which I've done in the past so you could do:

@form.delete({ action: route('redis.flush') })
@end

Yeah, that's a great question, and the approach you'd take will vary depending on either expectations or production data as you don't want to solve issues that don't/won't exist.

In our application, my expectation is that no one realistically would use more than 5 organizations. Since it isn't something I foresee being an issue within our application, if anything, just setting an overflow on the dropdown group listing the user's organizations would be the solution.

.organization-select div[role="group"] {
  max-height: calc(100vh - 230px);
  overflow-y: auto;
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

We could then do occasional audits on production data to check for use-cases where our expectations may have been wrong and our game plan needs altered.

If, however, production data shows or our expectations were that users would have 10+ organizations we'd want to take a different approach. It wouldn't be a good experience to list that many organizations within the dropdown; 5 would be ideal, 10 would probably be the max we'd want to show.

So, what we could do is add a timestamp column to the organization_users pivot table to store when the user last used the organization, maybe called last_used_at. Within our SetActiveOrganization action, we'd be sure to update this timestamp for the user's new active organization.

Then, within our OrganizationMiddleware where we are getting the user's organizations to list in the dropdown, we'd add a descending order for the last_used_at column and limit the results to 5. Resulting in the user's last 5 used organizations being shown in their dropdown. Then, we'd add one more option to their dropdown called "View All Organizations." This could then link to a new paginated page listing all the user's organizations, again defaulting this list to a descending sort by the last_used_at.

Alternatively, you could just let the user set their own preferred ordering like we did with our difficulties, access levels, etc.

Hi n2zb! Imports using the @ character, like @adonisjs/core are actual NPM packages/dependencies installed within our application. The @ character in NPM designates a scoped package. Scoped packages provide a way for the package maintainer to keep all their packages grouped together within the NPM registry. Additionally, it also provides some verification to installers as once a scope is claimed, one the user/organization that claimed the scope may use it.

For example, since the AdonisJS Core Team claimed @adonisjs only they can register packages using the @adonisjs scope on NPM.

The # imports, on the other hand, are an actual NodeJS feature called Subpath Imports. These are path aliases pointing to actual files within your project. Let's say we're importing a model:

import User from '../models/user.js'

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Without using a path alias, we need to traverse to the directory our models are within, for example using ../ to go back a directory. We also need to use the .js extension, required by ES Modules as they resolved and cached as URLs.

However, if we define a Subpath Import for our models:

{
  "imports": {
    "#models/*": "./app/models/*.js"
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

NodeJS will use this as a reference to fill in the blanks, allowing us to drop the relative paths to the files we're after and simplifying our imports.

import User from '#models/user'

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hope this helps clear things up!!

Hi n2zb! We started our CacheService without using Redis, but rather an in-memory key/value store. We kept using the CacheService even with Redis for a couple reasons.

1. I felt it would be easier to understand and follow by refactoring our preexisting service to use Redis rather than directly replacing the service with Redis. That way the before/after is all in one file.

2. To keep the JSON parse & stringify calls abstracted to the service's get & set methods.

3. When we have things like this that may be swapped out at some point, I like to keep them abstracted in my code to simplify any updates down the road. For example, if this lesson were released today we would've used Bentocache rather than the AdonisJS Redis package directly as Bentocache is specially attuned for caching with Redis - and will be used for the official AdonisJS Cache package coming soon.

So yes, you're pretty spot on! 😊

Yes, thank you very much cinqi! When v4 launched I added a note to the top of this lesson, but failed to realize the plugin Shadcn-Vue uses likely isn't up-to-date with that yet. I've updated my note to recommend sticking to v3 for now when following this series.

I also have a patch to the video being rendered as we speak, which I should be able to get updated tomorrow.

I'm really happy to hear you're enjoying AdonisJS, mrs3rver!! 😃

Thank you very much, I greatly appreciate that!!

Thank you, mrs3rver!!

Anytime, Aaron!!

Ah okay! Do you still have the TailwindCSS CDN & project presets within your inertia_layout.edge file? That could be clashing with the config we set up in lesson 1.4. I think we also clear those defaults out in that lesson as well.

If you'd like some additional eyes on it, please feel free to share a link to the repo! 😊

That's odd - do the tailwind classes work okay? Maybe your colors got adjusted, if you followed the Shadcn-Vue setup one-to-one, the colors used by Shadcn-Vue should be defined inside our app.css file. Do your colors match mine here? Otherwise, I think the other option in the Shadcn-Vue setup puts them in the tailwind.config.js file.

Hi Arron!

Great question, I now wish I would've injected this into the lesson; I think I'll make a note to do that.

The Referrer-Policy mentioned is a response header. So, in the controller rendering this page you'd add it using the HttpContext's response, like below. This is a step recommended by OWASP.

async reset({ params, inertia, response }: HttpContext) {
  const { isValid, user } = await VerifyPasswordResetToken.handle({ 
    encryptedHash: params.hash 
  })

  response.header('Referrer-Policy', 'no-referrer') // 👈

  return inertia.render('auth/forgot_password/reset', {
    hash: params.hash,
    email: user?.email,
    isValid,
  })
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Anytime!! 😊

This was answered on Discord, but I'll go ahead and answer here in case others come across it wondering the same.

EdgeJS renders HTML markup on your AdonisJS server while AlpineJS mutates the markup in the browser. Once the markup reaches the browser, EdgeJS has already done its job and is out of the picture, so what is being asked isn't possible.

Instead you'll need to use a client-side solution, like Tuyau, if you want to generate routes. Or, you can just hard code the route and use AlpineJS to populate the id that way.

<form :action="`/reviews/update/${selectedReview}`">
</form>

Hi gribbl!!

So, I looked into this a little bit, and it seems like everything TypeScript related for these components that are auto-imported via unplugin-vue-components begins working if you add the generated components.d.ts file into the /intertia/tsconfig.json include array, like below.

{
  "extends": "@adonisjs/tsconfig/tsconfig.client.json",
  "compilerOptions": {
    "baseUrl": ".",
    "jsx": "preserve",
    "module": "ESNext",
    "jsxImportSource": "vue",
    "paths": {
      "~/*": ["./*"],
    }
  },
  "include": ["./**/*.ts", "./**/*.vue", "../components.d.ts"]
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Here's the result:

I'm going to go tack a note about this into lesson 1.4, where we setup unplugin-vue-components!

Hi Aaron! Maybe try giving VSCode a reload by hitting cmd + shift + p then select for "Developer: Reload Window"

There's a bug in VSCode that creeps up every once in a while that causes Vue files to lose intellisense & auto imports. Even You (Vue's creator) posted about it a few months ago; you might be getting caught in that bug here. Reloading usually resolves it when I run into it.

Anytime!! 😊

Hi Rafal! Yeah, both are possible! Just like getters, setters can't be asynchronous. However, methods can be asynchronous.

export default class User extends BaseModel {
  // ...

  @column()
  declare active: boolean

  set isActive(value: boolean) {
    this.active = value
  }

  deactivate() {
    this.active = false
  }
}

const user = new User()

user.isActive = false
user.deactivate()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Yeah, you can do that via a migration! There is an index and dropIndex method for that. The KnexJS documentation has more info on the options these accept, which will vary depending on your database driver.

import { BaseSchema } from '@adonisjs/lucid/schema'

export default class extends BaseSchema {
  protected tableName = 'index_examples'

  async up() {
    this.schema.alterTable(this.tableName, (table) => {
      // single
      table.index('column_one')

      // multi-column
      table.index(['column_two', 'column_three'])

      // custom named
      table.index(['column_four'], 'custom_index_name', { /* additional opts */ })
    })
  }

  async down() {
    this.schema.alterTable(this.tableName, (table) => {
      // single
      table.dropIndex('column_one')

      // multi-column
      table.dropIndex(['column_two', 'column_three'])

      // custom named
      table.dropIndex(['column_four'], 'custom_index_name')
    })
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hi, csaba-kiss!! You can try registering radix-vue's unplugin-vue-components plugin to see if that helps. The caveat here is you'll likely need to use the original name defined in radix-vue, rather than renamed components from shadcn-vue.

For example, to auto-import, you'd probably need to use the name "SplitterPanel" rather than shadcn-vue's "ResizablePanel."

I noticed a similar issue when rebuilding the Adocasts CMS and opted to import the components directly instead.

import Components from 'unplugin-vue-components/vite'
import RadixVueResolver from 'radix-vue/resolver'

export default defineConfig({
  plugins: [
    vue(),
    Components({
      dts: true,
      resolvers: [
        RadixVueResolver()

        // RadixVueResolver({
        //   prefix: '' // use the prefix option to add Prefix to the imported components
        // })
      ],
    }),
  ],
})

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

That's awesome to hear marion-huet!!! Thank you for watching! I hope you enjoyed and also found everything easy to understand and follow.

Awesome, I'm glad to hear that, gribbl!! Anytime!!

Anytime! 😊

Anytime!! Yeah, they grow pretty easily & quickly!! lol 😅

As a whole, by using actions you're:

• Giving the operation a name & scope, which improves the ability to scan your controllers.

• Gives us the ability to easily reuse the code if needed. It is considered bad practice to call one controller method from another, as controllers are meant to handle routes.

• On top of reusability, if we need to update an operation later on, we only have to perform that update in one spot rather than each spot it is performed in the controllers.

• As you said, it gives us a separation of concerns. If we're performing an action, we know we can find it within our actions folder, under the resource/section it is for.

Note that actions are very similar to services. To compare, you can think of each subfolder within actions as a service class and each file within the subfolder as a service class method. The main difference here though is actions allow us to easily define steps within the actions whereas that'd need to be additional methods inside a service, which can make things a little messy.

A good example, though the code for this is from a future lesson releasing soon, is the account deletion controller & action. The controller is easy to scan. The operations have a designated location & scope and can make use of subactions. We're reusing our webLogout method, meaning we can easily update just the webLogout method if we ever need to adjust how we handle logouts. For example, if you're tracking user sessions, you might need to mark that session record in the database as logged out in addition to actually logging out the user.

@inject()
async destroy({ request, response, session, auth }: HttpContext, webLogout: WebLogout) {
  const user = auth.use('web').user!
  const validator = vine.compile(
    vine.object({
      email: vine.string().in([user.email]),
    })
  )

  await request.validateUsing(validator)

  await DestroyUserAccount.handle({ user })

  await webLogout.handle()

  session.flash('success', 'Your account has been deleted')

  return response.redirect().toRoute('register.show')
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

I've worked with code, and written my fair share, where the controller method gets unwieldy large because all the operations are done directly in the controller. It might seem small at first, but requirements change, time gets crunched, and things slowly grow over time.

Hope this helps!

Are you using NPM directly within Powershell? Powershell reserved the @ character for their splatting feature. Which means you'll either need to escape that character or wrap it in strings, as you found.

We're using DTOs because getting an accurate serialized type for Lucid models isn't currently possible. If you use the model as a type directly in Inertia, the type will include things you don't have access to in your frontend, like .merge({}), .save(), .related('organizations'), etc.

If you use just the model's attributes, that won't include relationships, extras, and also won't take into account serialization alterations on the model like serializeAs.

So, currently, it is due to technical constraints in Lucid and would require some hefty refactors to remedy. Yeah, if you were trying to do end-to-end types with an API you'd run into the same constraint.

Yeah, those seem to be the areas most struggle with on APIs 😊. Using the PlotMyCourse application also gives us a cool opportunity to cover authentication with a non-user entity.

I'm so sorry, my head was in the wrong spot! You're absolutely right, the /storage gets added to the saved value in the database so the unlink should be:

await unlink(app.makePath('.', movie.posterUrl))

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Terribly sorry for the confusion there! I'll make a note to correct this lesson.

Hi gribbl! Thank you for sharing! Yeah, I had missed a number of Vue 3.4's enhancements. I apologize we didn't use any of them in this series. As for 3.5's enhancements, this codebase is still on 3.4 - I don't want to update any packages mid-series until we get to the end where we'll focus on Inertia v2's changes.

Thank you, yunus! I very much agree in regards to using Inertia over meta frameworks when you need the full stack! 😊

As for deployment, please see my comment here. The TLDR is it's coming, but not something I do myself all that often. So I just need to dedicate some time to do proper R&D to do some lessons justice. 😁

Yes, thank you for sharing!! Once completed, we'll be adding a new module to the end of this series covering what's new in Inertia v2 and the AdonisJS adapter and I'll circle back and add/edit some lessons to include notes for outdated things like this.

Yes, it absolutely would, thank you very much kite!! I have no clue how I overlooked that. I'll try and get this added tomorrow after work!

Hi yunus! Apologies for the delayed response! I'm not familiar with the SolidJS ecosystem in the slightest, so I unfortunately do not know. You might have luck using unplugin-auto-import, that is what unplugin-vue-components utilizes, but I'm not certain whether it'll work nor how it'd need to be configured.

Yeah, I absolutely love Vue & it's ecosystem!! Thank you for sharing these plugins' gribbl!! 😊

Thank you for watching, gribbl! I'm ecstatic to hear you learned a lot from it and are loving AdonisJS!!

I discovered AdonisJS back in the early AdonisJS 4 days. I was previously working with Laravel, but I work primarily with JavaScript and found AdonisJS searching for a JavaScript alternative to Laravel. 😊

I've had a lot of requests for some API content, so we'll be doing a series on adding an API to the PlotMyCourse application we're currently making in the Building with AdonisJS & Inertia series. On top of that, we'll also be doing a todo series, showing how to make a todo app in a bunch of different ways with AdonisJS. I have some other ideas on our schedule page, but those are more open to changes before we get to them. I like the idea of an e-commerce site, I'll add that to the ideas, thank you for the suggestion!! 😊

Happy New Year to you as well!! 🎉

Yep - you're absolutely right, sorry about that! Tacking one more property into the object specifically to uniquely identify the row would fix it up and Math.random() is usually what I reach for as well for those use cases.

I like to use the below because the _ prefix ensures it can also be used in the id attribute if needed.

const uniqueId = '_' + Math.random().toString(36).substr(2, 9)

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Sorry for the delayed response! Are you able to share the repo url? Neither should be the case, and I can't immediately think of anything that would cause either of those.

My pleasure, Mohamed!! 😊

Hi Gribbl!

If you're able to directly access the file via the URL without going through a route definition, that leads me to believe the file is actually within your public directory. Files within this directory are made accessible by the AdonisJS static file server.

That would also explain the "no such file" error on the attempted deletion, as app.makePath('storage') is going to be looking in the ~/storage directory directly off your application root, not within the public directory.

Can't say for certain though - just making an educated guess based on the info provided.

Hope this helps!

Hi Mohamed!

Good question about production deployment! While I don't currently plan on including it in the "Building with AdonisJS & Inertia" series, it's absolutely on my radar and something I plan to cover in the future.

It's not my strongest area, and I don't regularly do it, so to sufficiently cover security concerns I need to invest some time into learning enough to do it justice. I currently use Cleavr, which does all that for me. After investing some R&D time, I may decide to tack it onto the end of the Inertia series or cover deployment in a series of its own.

Hi sivaclikry! As of right now, there is no way to generate models and migrations from an existing database. So, you'll want to manually define the models and migrations you'll need.

I have a package that is a work in progress, you're welcome to try it. It'll generate models for you, but it doesn't currently do migrations. Right now, it'll work best with MySQL & PostgreSQL.

To install, you can run:

npm add @adocasts.com/generate-models

Ensure your db connection is defined and working in your .env , then generate with:

node ace generate:models

Hi laithong! I haven't yet worked with Trasmit, but I don't believe using Inertia should change its implementation any from what is covered in the docs.

The server-side installation would be the same as covered in the documentation; installing the packages, configuring your Redis connection, registering the routes, and defining the channels.

Then, you'd define the client initialization inside a file within your Inertia directory, somewhere like ~/inertia/lib/transmit.ts, and import it where needed. I imagine the client will only work client-side in the browser. So, you may want to ensure whatever imports your transmit file is running only on the client and not using SSR. I'm not certain on that though.

Wow - thanks a ton for sharing this, Jeffrey! I completely missed Vue adding in the defineModel macro, that's a huge improvement!!

Similar to Lucid, when you configure the AdonisJS Mail package, it'll ask you specifically which drivers you intend to use and it will only install those applicable to your selections.

Hi gribbl! Yep, absolutely!! It is officially documented within Lucid's documentation!! 🥳 A great new addition!

Hi mojtaba-rajabi! I wouldn't recommend trying to redirect the user from inside a method on the model.

1. There's a high probability the redirect would get forgotten about should you ever need to debug

2. You'd still need to terminate the request inside the controller method/route handler.

If this is for AdonisJS 6, what I would recommend instead is to let the framework do its thing. The findForAuth method is called by the verifyCredentials method. This method purposefully hashes the provided password, regardless if a user is found or not, so that there isn't a timing difference between the two. Reducing the ability for a bad actor to scrape your login form for credentials &/or valid emails using a timing attack.

This verifyCredentials method then throws an exception if the login is wrong, which you can capture and display on the frontend. This exception is available via the errorsBag flash message. That covers your if (!user) check.

Then, I would let verifyCredentials return back the user if one is found, regardless of the isActive flag and instead check that isActive flag after verifying the credentials. That way:

• You can keep timing attack protections AdonisJS set for you in place

• You know the user is correct, since they know their credentials, so you can guide them (if applicable) on how to activate their account.

• You don't have any sneaky code doing things in places you might not expect a year or two down the road.

You can then easily pass along whatever message you'd like via Inertia using flash messaging.

public async login({ request, response, session, auth }: HttpContex) {
  const { uid, password } = await request.validateUsing(loginValidator)
  const user = await User.verifyCredentials(uid, password)

  if (!user.isActive) {
    session.flash('error', 'Please activate your account')
    return response.redirect().back()
  }

  await auth.use('web').login(user)

  return response.redirect().toRoute('dashboard')
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hope this helps!

Anytime, jabir!

Hi Pierrick, thank you for watching!

You can find this within lesson 1.1 - "What We'll Need Before We Begin." At the 3:10 mark, we created the database "adonis6" for use in this series, I apologize; it seems I misspoke and said table in this lesson when I meant database.

Anytime! Yep, definitely some movement there!! 😊

Thank you, Thomas!

Anytime!!

I'm fairly certain the browser displays the popup before the response of the request is actually received, at least that is the behavior I've noticed in the past with Firefox (the browser I use).

I, unfortunately, don't think or know of a way where is a way to enable/disable depending on success. I tested on Laravel Forge's site and still got the popup with invalid credentials (screenshot below). I can't say for certain it is impossible to do, but to the best of my knowledge I'm not aware of a way. Sorry, I know I haven't been much of a help here.

So long as the underlying data columns remain the same and the changes you're looking to do adhere to the type requirements set by the @adonisjs/auth package I don't think there would be any issues with reusing the table for other tokens. I don't foresee an enum column type causing issues either, so long as you include auth_token as one of the values in the enum.

If you give it a try, let me know how it goes! 😊

Hi jabir!

1. This is a native browser behavior when forms are submitted with a password field. So, I suppose one way would be to not use the type="password" on the input, but I wouldn't recommend that as prying eyes could easily grab someones credentials. There's a long discussion on StackOverflow of some attributes that may do the trick, though I'm not sure which are working as of today since browsers tend to change behaviors like this over time.

2. Is this with forward navigation or using the browser's back button? If it is with the browser's back button, I don't think there is much you can do as that restores the saved state of the page in the browser's navigation history. The behavior you see there is going to match any multi-page application. If it is forward navigation, then that shouldn't be happening and there is likely a state update issue somewhere in your code. Happy to help dig in if it is a forward navigation issue and you're able to share code.

Anytime! Awesome, I'm happy to hear you were able to track it down and get it all fixed up! 😊 Another alternative, if applicable to your use-case, is to reflash any messages. This will push the flash messages forward with a secondary redirection.

Flash → redirect home → reflash & redirect family.show

export default class UserHasFamilyMiddleware {
  async handle({ auth, response, session }: HttpContext, next: NextFn) {
    if (auth.user && auth.user.hasNoFamily()) {
      session.reflash()
      return response.redirect().toRoute('family.show')
    }
    return next()
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

My pleasure, thank you for the suggestion! 😊

Hi noctisy!

This is something I've been meaning to add, but kept slipping off my radar.

I'll preface by saying I'm not going to add download support for videos we only have hosted on YouTube, which are typically our older videos. Though that is technically possible, I'm sure that'd be against some ToS of theirs and I do plan on moving these videos over to our storage service anyways.

As for our newer videos, which I think fully encompasses all of our AdonisJS 6 lessons, I've just deployed out an update to add a download button for Adocasts Plus subscribers! You can find it just below the video. Again, this is brand new, so if you run into any issues please do let me know!

As a warning, a lot of our videos are uploaded as WEBM, and that is how they'll download as well. So, you'll need to use a video player that supports WEBM videos.

Anytime! Ah - then it'll be import app from '@adonisjs/core/services/app'

import app from '@adonisjs/core/services/app'

class SocketioService {
  inProduction() {
    return app.inProduction
  }
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hi davidtazy!

Yeah, the toast system should be fully working by the end of this lesson. And, in fact, In lesson 5.2 Logging Out Users, we add in a session.flash('success' Welcome to PlotMyCourse') after successfully registering the user.

Are you redirecting the user after registering them? Flash messages are made available for the next request and won't be applied to the current, so the redirect does serve a purpose here.

Here is the final RegisterController's Store method.

@inject()
async store({ request, response, session }: HttpContext, webRegister: WebRegister) {
  const data = await request.validateUsing(registerValidator)

  // register the user
  await webRegister.handle({ data })

  session.flash('success', 'Welcome to PlotMyCourse')

  return response.redirect().toRoute('organizations.create')
}

  

    

      Copied!