In the last lesson, we hardcoded a document ID placeholder in the token API endpoint. view file, you'll see that that same placeholder is used there too. This ID is what distinguishes one document from another. So instead of hardcoding that into the component, let's turn it into a prop, which means we can remove the definition of the hardcoded document ID Then when configuring the document ID with the editor, we'll use the ID from the props.
And whoops, before I do that, let me extract the props from the definition. Great. Now look for channel ID. Here is that configuration object that's passed to CKEditor.
documentID. Awesome. view. Let's pass in a dynamic ID based on a query string in the URL.
We'll access the route with use route, and then define a computed property document ID that gets the query variable ID. This could be done in a variety of ways, of course, in your own apps. But usually there's a unique query variable or a route param in your URL somewhere that identifies the document. Lastly, Let's also provide a default ID just in case none is provided.
Oh, and we'll also have to pass in the document ID to the editor component. Over in the browser, if I try to view the document now, notice that it doesn't load, and we've got an error in the console. The error is extremely straightforward. We don't have enough permissions to access this resource.
Well, that's because over in the token endpoint, we've said that our user can only write to a document with the ID of your document ID. We've said absolutely nothing about what they can do with a document ID default ID. Can't you see just the level of control that this simple token endpoint is giving us? It's really spectacular and easy to do.
we could add as many document IDs and role pairs into the token as we'd like. For example, let's add the role of commentator for the default ID. Now in the browser, I can view the document, but I can't edit it. If I visit the URL with the placeholder ID though from before, then I can edit no problem.
Alternatively, if we wanted to give the same role to a user for all documents, then we could use a star in the place of the document ID. This means then that this user can write to all documents and modify all the comments on all documents. To sum up, the document ID is useful for identifying documents and what permissions the user has on what docs. In the next lesson, you'll learn how to store document content permanently based on this ID.
In the last lesson, we hardcoded a document ID placeholder in the token API endpoint. view file, you'll see that that same placeholder is used there too. This ID is what distinguishes one document from another. So instead of hardcoding that into the component, let's turn it into a prop, which means we can remove the definition of the hardcoded document ID Then when configuring the document ID with the editor, we'll use the ID from the props.
And whoops, before I do that, let me extract the props from the definition. Great. Now look for channel ID. Here is that configuration object that's passed to CKEditor.
documentID. Awesome. view. Let's pass in a dynamic ID based on a query string in the URL.
We'll access the route with use route, and then define a computed property document ID that gets the query variable ID. This could be done in a variety of ways, of course, in your own apps. But usually there's a unique query variable or a route param in your URL somewhere that identifies the document. Lastly, Let's also provide a default ID just in case none is provided.
Oh, and we'll also have to pass in the document ID to the editor component. Over in the browser, if I try to view the document now, notice that it doesn't load, and we've got an error in the console. The error is extremely straightforward. We don't have enough permissions to access this resource.
Well, that's because over in the token endpoint, we've said that our user can only write to a document with the ID of your document ID. We've said absolutely nothing about what they can do with a document ID default ID. Can't you see just the level of control that this simple token endpoint is giving us? It's really spectacular and easy to do.
we could add as many document IDs and role pairs into the token as we'd like. For example, let's add the role of commentator for the default ID. Now in the browser, I can view the document, but I can't edit it. If I visit the URL with the placeholder ID though from before, then I can edit no problem.
Alternatively, if we wanted to give the same role to a user for all documents, then we could use a star in the place of the document ID. This means then that this user can write to all documents and modify all the comments on all documents. To sum up, the document ID is useful for identifying documents and what permissions the user has on what docs. In the next lesson, you'll learn how to store document content permanently based on this ID.