As the author of a library called AgnosticUI, I’m always on the lookout for new components. And recently, I decided to dig in and start work on a new dialog (aka modal) component. That’s something many devs like to have in their toolset and my goal was to make the best one possible, with an extra special focus on making it inclusive and accessible.
My first thought was that I would avoid any dependencies and bite the bullet to build my own dialog component. As you may know, there’s a new <dialog>
element making the rounds and I figured using it as a starting point would be the right thing, especially in the inclusiveness and accessibilities departments.
But, after doing some research, I instead elected to leverage a11y-dialog by Kitty Giraudel. I even wrote adapters so it integrates smoothly with Vue 3, Svelte, and Angular. Kitty has long offered a React adapter as well.
Why did I go that route? Let me take you through my thought process.
First question: Should I even use the native <dialog>
element?
The native <dialog>
element is being actively improved and will likely be the way forward. But, it still has some issues at the moment that Kitty pointed out quite well:
- Clicking the backdrop overlay does not close the dialog by default
- The
alertdialog
ARIA role used for alerts simply does not work with the native<dialog>
element. We’re supposed to use that role when a dialog requires a user’s response and shouldn’t be closed by clicking the backdrop, or by pressingESC
. - The
<dialog>
element comes with a::backdrop
pseudo-element but it is only available when a dialog is programmatically opened withdialog.showModal()
.
And as Kitty also points out, there are general issues with the element’s default styles, like the fact they are left to the browser and will require JavaScript. So, it’s sort of not 100% HTML anyway.
Here’s a pen demonstrating these points:
Now, some of these issues may not affect you or whatever project you’re working on specifically, and you may even be able to work around things. If you still would like to utilize the native dialog you should see Adam Argyle’s wonderful post on building a dialog component with native dialog.
OK, let’s discuss what actually are the requirements for an accessible dialog component…
What I’m looking for
I know there are lots of ideas about what a dialog component should or should not do. But as far as what I was personally going after for AgnosticUI hinged on what I believe make for an accessible dialog experience:
- The dialog should close when clicking outside the dialog (on the backdrop) or when pressing the
ESC
key. - It should trap focus to prevent tabbing out of the component with a keyboard.
- It should allow forwarding tabbing with
TAB
and backward tabbing withSHIFT
+TAB
. - It should return focus back to the previously focused element when closed.
- It should correctly apply
aria-*
attributes and toggles. - It should provide Portals (only if we’re using it within a JavaScript framework).
- It should support the
alertdialog
ARIA role for alert situations. - It should prevent the underlying body from scrolling, if needed.
- It would be great if our implementation could avoid the common pitfalls that come with the native
<dialog>
element. - It would ideally provide a way to apply custom styling while also taking the
prefers-reduced-motion
user preference query as a further accessibility measure.
I’m not the only one with a wish list. You might want to see Scott O’Hara’s article on the topic as well as Kitty’s full write-up on creating an accessible dialog from scratch for more in-depth coverage.
It should be clear right about now why I nixed the native <dialog>
element from my component library. I believe in the work going into it, of course, but my current needs simply outweigh the costs of it. That’s why I went with Kitty’s a11y-dialog as my starting point.
Auditing <dialog>
accessibility
Before trusting any particular dialog implementation, it’s worth making sure it fits the bill as far as your requirements go. With my requirements so heavily leaning on accessibility, that meant auditing a11y-dialog.
Accessibility audits are a profession of their own. And even if it’s not my everyday primary focus, I know there are some things that are worth doing, like:
- manually verifying the functionality listed above, of course in different browsers,
- using accessibility tooling like Lighthouse, IBM Equal Access Accessibility Checker, Deque’s AXE, and WAVE to help find insights and uncover issues,
- testing with real screen readers, like JAWS, NVDA, and VoiceOver, and
- testing the component on real people.
This is quite a lot of work, as you might imagine (or know from experience). It’s tempting to take a path of less resistance and try automating things but, in a study conducted by Deque Systems, automated tooling can only catch about 57% of accessibility issues. There’s no substitute for good ol’ fashioned hard work.
The auditing environment
The dialog component can be tested in lots of places, including Storybook, CodePen, CodeSandbox, or whatever. For this particular test, though, I prefer instead to make a skeleton page and test locally. This way I’m preventing myself from having to validate the validators, so to speak. Having to use, say, a Storybook-specific add-on for a11y verification is fine if you’re already using Storybook on your own components, but it adds another layer of complexity when testing the accessibility of an external component.
A skeleton page can verify the dialog with manual checks, existing a11y tooling, and screen readers. If you’re following along, you’ll want to run this page via a local server. There are many ways to do that; one is to use a tool called serve, and npm even provides a nice one-liner npx serve <DIRECTORY>
command to fire things up.
Let’s do an example audit together!
I’m obviously bullish on a11y-dialog here, so let’s put it to the test and verify it using some of the the recommended approaches we’ve covered.
Again, all I’m doing here is starting with an HTML. You can use the same one I am (complete with styles and scripts baked right in).
View full code
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <title>A11y Dialog Test</title> <style> .dialog-container { display: flex; position: fixed; top: 0; left: 0; bottom: 0; right: 0; z-index: 2; } .dialog-container[aria-hidden='true'] { display: none; } .dialog-overlay { position: fixed; top: 0; left: 0; bottom: 0; right: 0; background-color: rgb(43 46 56 / 0.9); animation: fade-in 200ms both; } .dialog-content { background-color: rgb(255, 255, 255); margin: auto; z-index: 2; position: relative; animation: fade-in 400ms 200ms both, slide-up 400ms 200ms both; padding: 1em; max-width: 90%; width: 600px; border-radius: 2px; } @media screen and (min-width: 700px) { .dialog-content { padding: 2em; } } @keyframes fade-in { from { opacity: 0; } } @keyframes slide-up { from { transform: translateY(10%); } } /* Note, for brevity we haven't implemented prefers-reduced-motion */ .dialog h1 { margin: 0; font-size: 1.25em; } .dialog-close { position: absolute; top: 0.5em; right: 0.5em; border: 0; padding: 0; background-color: transparent; font-weight: bold; font-size: 1.25em; width: 1.2em; height: 1.2em; text-align: center; cursor: pointer; transition: 0.15s; } @media screen and (min-width: 700px) { .dialog-close { top: 1em; right: 1em; } } * { box-sizing: border-box; } body { font: 125% / 1.5 -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif; padding: 2em 0; } h1 { font-size: 1.6em; line-height: 1.1; font-family: 'ESPI Slab', sans-serif; margin-bottom: 0; } main { max-width: 700px; margin: 0 auto; padding: 0 1em; } </style> <script defer src="https://cdn.jsdelivr.net/npm/a11y-dialog@7/dist/a11y-dialog.min.js"></script> </head> <body> <main> <div class="dialog-container" id="my-dialog" aria-hidden="true" aria-labelledby="my-dialog-title" role="dialog"> <div class="dialog-overlay" data-a11y-dialog-hide></div> <div class="dialog-content" role="document"> <button data-a11y-dialog-hide class="dialog-close" aria-label="Close this dialog window"> × </button> <a href="https://www.yahoo.com/" target="_blank">Rando Yahoo Link</a> <h1 id="my-dialog-title">My Title</h1> <p id="my-dialog-description"> Some description of what's inside this dialog… </p> </div> </div> <button type="button" data-a11y-dialog-show="my-dialog"> Open the dialog </button> </main> <script> // We need to ensure our deferred A11yDialog has // had a chance to do its thing ;-) window.addEventListener('DOMContentLoaded', (event) => { const dialogEl = document.getElementById('my-dialog') const dialog = new A11yDialog(dialogEl) }); </script> </body> </html>
I know, we’re ignoring a bunch of best practices (what, styles in the <head>
?!) and combined all of the HTML, CSS, and JavaScript in one file. I won’t go into the details of the code as the focus here is testing for accessibility, but know that this test requires an internet connection as we are importing a11y-dialog from a CDN.
First, the manual checks
I served this one-pager locally and here are my manual check results:
Feature | Result |
---|---|
It should close when clicking outside the dialog (on the backdrop) or when pressing the ESC key. |
✅ |
It ought to trap focus to prevent tabbing out of the component with a keyboard. | ✅ |
It should allow forwarding tabbing with TAB and backward tabbing with SHIFT +TAB . |
✅ |
It should return focus back to the previously focused element when closed. | ✅ |
It should correctly apply aria-* attributes and toggles. |
✅ I verified this one “by eye” after inspecting the elements in the DevTools Elements panel. |
It should provide Portals. | Not applicable. This is only useful when implementing the element with React, Svelte, Vue, etc. We’ve statically placed it on the page with aria-hidden for this test. |
It should support for the alertdialog ARIA role for alert situations. |
✅ You’ll need to do two things: First, remove
Now, clicking on the overlay outside of the dialog box does not close the dialog, as expected. |
It should prevent the underlying body from scrolling, if needed. | ✅ I didn’t manually test but this, but it is clearly available per the documentation. |
It should avoid the common pitfalls that come with the native <dialog> element. |
✅ This component does not rely on the native <dialog> which means we’re good here. |
Next, let’s use some a11y tooling
I used Lighthouse to test the component both on a desktop computer and a mobile device, in two different scenarios where the dialog is open by default, and closed by default.

I’ve found that sometimes the tooling doesn’t account for DOM elements that are dynamically shown or hidden DOM elements, so this test ensures I’m getting full coverage of both scenarios.
I also tested with IBM Equal Access Accessibility Checker. Generally, this tool will give you a red violation error if there’s anything egregious wrong. It will also ask you to manually review certain items. As seen here, there a couple of items for manual review, but no red violations.

Moving on to screen readers
Between my manual and tooling checks, I’m already feeling relatively confident that a11y-dialog
is an accessible option for my dialog of choice. However, we ought to do our due diligence and consult a screen reader.
VoiceOver is the most convenient screen reader for me since I work on a Mac at the moment, but JAWS and NVDA are big names to look at as well. Like checking for UI consistency across browsers, it’s probably a good idea to test on more than one screen reader if you can.

Here’s how I conducted the screen reader part of the audit with VoiceOver. Basically, I mapped out what actions needed testing and confirmed each one, like a script:
Step | Result |
---|---|
The dialog component’s trigger button is announced. | “Entering A11y Dialog Test, web content.” |
The dialog should open when pressing CTRL +ALT +Space should show the dialog. |
“Dialog. Some description of what’s inside this dialog. You are currently on a dialog, inside of web content.” |
The dialog should TAB to and put focus on the component’s Close button. |
“Close this dialog button. You are currently on a button, inside of web content.” |
Tab to the link element and confirm it is announced. | “Link, Rando Yahoo Link” |
Pressing the SPACE key while focused on the Close button should close the dialog component and return to the last item in focus. |
✅ |
Testing with people
If you’re thinking we’re about to move on to testing with real people, I was unfortunately unable to find someone. If I had done this, though, I would have used a similar set of steps for them to run through while I observe, take notes, and ask a few questions about the general experience.
As you can see, a satisfactory audit involves a good deal of time and thought.
Fine, but I want to use a framework’s dialog component
That’s cool! Many frameworks have their own dialog component solution, so there’s lots to choose from. I don’t have some amazing spreadsheet audit of all the frameworks and libraries in the wild, and will spare you the work of evaluating them all.
Instead, here are some resources that might be good starting points and considerations for using a dialog component in some of the most widely used frameworks.
Disclaimer: I have not tested these personally. This is all stuff I found while researching.
Angular dialog options
In 2020, Deque published an article that audits Angular component libraries and the TL;DR was that Material (and its Angular/CDK library) and ngx-bootstrap both appear to provide decent dialog accessibility.
React dialog options
Reakit offers a dialog component that they claim is compliant with WAI-ARIA dialog guidelines, and chakra-ui appears to pay attention to its accessibility. Of course, Material is also available for React, so that’s worth a look as well. I’ve also heard good things about reach/dialog and Adobe’s @react-aria/dialog.
Vue dialog options
I’m a fan of Vuetensils, which is Austin Gil’s naked (aka headless) components library, which just so happens to have a dialog component. There’s also Vuetify, which is a popular Material implementation with a dialog of its own. I’ve also crossed paths with PrimeVue, but was surprised that its dialog component failed to return focus to the original element.
Svelte dialog options
You might want to look at svelte-headlessui. Material has a port in svelterial that is also worth a look. It seems that many current SvelteKit users prefer to build their own component sets as SvelteKit’s packaging idiom makes it super simple to do. If this is you, I would definitely recommend considering svelte-a11y-dialog as a convenient means to build custom dialogs, drawers, bottom sheets, etc.
I’ll also point out that my AgnosticUI library wraps the React, Vue, Svelte and Angular a11y-dialog
adapter implementations we’ve been talking about earlier.
Bootstrap, of course
Bootstrap is still something many folks reach for, and unsurprisingly, it offers a dialog component. It requires you to follow some steps in order to make the modal accessible.
If you have other inclusive and accessible library-based dialog components that merit consideration, I’d love to know about them in the comments!
But I’m creating a custom design system
If you’re creating a design system or considering some other roll-your-own dialog approach, you can see just how many things need to be tested and taken into consideration… all for one component! It’s certainly doable to roll your own, of course, but I’d say it’s also extremely prone to error. You might ask yourself whether the effort is worthwhile when there are already battle-tested options to choose from.
I’ll simply leave you with something Scott O’Hara — co-editor of ARIA in HTML and HTML AAM specifications in addition to just being super helpful with all things accessibility — points out:
You could put in the effort to add in those extensions, or you could use a robust plugin like a11y-dialog and ensure that your dialogs will have a pretty consistent experience across all browsers.
Back to my objective…
I need that dialog to support React, Vue, Svelte, and Angular implementations.
I mentioned earlier that a11y-dialog already has ports for Vue and React. But the Vue port hasn’t yet been updated for Vue 3. Well, I was quite happy to spend the time I would have spent creating what likely would have been a buggy hand-rolled dialog component toward helping update the Vue port. I also added a Svelte port and one for Angular too. These are both very new and I would consider them experimental beta software at time of writing. Feedback welcome, of course!
It can support other components, too!
I think it’s worth pointing out that a dialog uses the same underlying concept for hiding and showing that can be used for a drawer (aka off-canvas) component. For example, if we borrow the CSS we used in our dialog accessibility audit and add a few additional classes, then a11y-dialog can be transformed into a working and effective drawer component:
.drawer-start { right: initial; } .drawer-end { left: initial; } .drawer-top { bottom: initial; } .drawer-bottom { top: initial; } .drawer-content { margin: initial; max-width: initial; width: 25rem; border-radius: initial; } .drawer-top .drawer-content, .drawer-bottom .drawer-content { width: 100%; }
These classes are used in an additive manner, essentially extending the base dialog component. This is exactly what I have started to do as I add my own drawer component to AgnosticUI. Saving time and reusing code FTW!
Wrapping up
Hopefully I’ve given you a good idea of the thinking process that goes into the making and maintenance of a component library. Could I have hand-rolled my own dialog component for the library? Absolutely! But I doubt it would have yielded better results than what a resource like Kitty’s a11y-dialog does, and the effort is daunting. There’s something cool about coming up with your own solution — and there may be good situations where you want to do that — but probably not at the cost of sacrificing something like accessibility.
Anyway, that’s how I arrived at my decision. I learned a lot about the native HTML <dialog>
and its accessibility along the way, and I hope my journey gave you some of those nuggets too.
Dialog Components: Go Native HTML or Roll Your Own? originally published on CSS-Tricks. You should get the newsletter.
Roll Your Own Comments With Gatsby and FaunaDB
If you haven’t used Gatsby before have a read about why it’s fast in every way that matters, and if you haven’t used FaunaDB before you’re in for a treat. If you’re looking to make your static sites full blown Jamstack applications this is the back end solution for you!
This tutorial will only focus on the operations you need to use FaunaDB to power a comment system for a Gatsby blog. The app comes complete with inputs fields that allow users to comment on your posts and an admin area for you to approve or delete comments before they appear on each post. Authentication is provided by Netlify’s Identity widget and it’s all sewn together using Netlify serverless functions and an Apollo/GraphQL API that pushes data up to a FaunaDB database collection.
I chose FaunaDB for the database for a number of reasons. Firstly there’s a very generous free tier! perfect for those small projects that need a back end, there’s native support for GraphQL queries and it has some really powerful indexing features!
…and to quote the creators;
You can see the finished comments app here.
Get Started
To get started clone the repo at https://github.com/PaulieScanlon/fauna-gatsby-comments
or:
Then install all the dependencies:
Also
cd
in tofunctions/apollo-graphql
and install the dependencies for the Netlify function:This is a separate package and has its own dependencies, you’ll be using this later.
We also need to install the Netlify CLI as you’ll also use this later:
Now lets add three new files that aren’t part of the repo.
At the root of your project create a
.env
.env.development
and.env.production
Add the following to
.env
:Add the following to
.env.development
:Add the following to
.env.production
:You’ll come back to these later but in case you’re wondering
GATSBY_FAUNA_DB
is the FaunaDB secret key for your databaseGATSBY_FAUNA_COLLECTION
is the FaunaDB collection nameGATSBY_SHOW_SIGN_UP
is used to hide the Sign up button when the site is in productionGATSBY_ADMIN_ID
is a user id that Netlify Identity will generate for youIf you’re the curious type you can get a taster of the app by running
gatsby develop
oryarn develop
and then navigate tohttp://localhost:8000
in your browser.FaunaDB
So Let’s get cracking, but before we write any operations head over to https://fauna.com/ and sign up!
Database and Collection
fauna-gatsby-comments
demo-blog-comments
Server Key
Now you’ll need to to set up a server key. Go to SECURITY
fauna-gatsby-comments
for exampledemo-blog-server-key
Environment Variables Pt. 1
Copy the server key and add it to
GATSBY_FAUNA_DB
in.env.development
,.env.production
and.env
.You’ll also need to add the name of the collection to
GATSBY_FAUNA_COLLECTION
in.env.development
,.env.production
and.env
.Adding these values to
.env
are just so you can test your development FaunaDB operations, which you’ll do next.Let’s start by creating a comment so head back to
boop.js
:The breakdown of this function is as follows;
q
is the instance offaunadb.query
Create
is the FaunaDB method to create an entry within a collectionCollection
is area in the database to store the data. It takes the name of the collection as the first argument and a data object as the second.The second argument is the shape of the data you need to drive the applications comment system.
For now you’re going to hard-code
slug
,name
andcomment
but in the final app these values are captured by the input form on the posts page and passed in via argsThe breakdown for the shape is as follows;
isApproved
is the status of the comment and by default it’s false until we approve it in the Admin pageslug
is the path to the post where the comment was writtendate
is the time stamp the comment was writtenname
is the name the user entered in the comments fromcomment
is the comment the user entered in the comments formWhen you (or a user) creates a comment you’re not really interested in dealing with the response because as far as the user is concerned all they’ll see is either a success or error message.
After a user has posted a comment it will go in to your Admin queue until you approve it but if you did want to return something you could surface this in the UI by returning something from the
createComment
function.Create a comment
If you’ve hard coded a
slug
,name
andcomment
you can now run the following in your CLIIf everything worked correctly you should see a log in your terminal of the new comment.
If you head over to COLLECTIONS in FaunaDB you should see your new entry in the collection.
You’ll need to create a few more comments while in development so change the hard-coded values for
name
andcomment
and run the following again.Do this a few times so you end up with at least three new comments stored in the database, you’ll use these in a moment.
Delete comment by id
Now that you can create comments you’ll also need to be able to delete a comment.
By adding the
commentId
of one of the comments you created above you can delete it from the database. ThecommentId
is theid
in theref.@ref
objectAgain you’re not really concerned with the return value here but if you wanted to surface this in the UI you could do so by returning something from the
deleteCommentById
function.The breakdown of this function is as follows
client
is the FaunaDB client instancequery
is a method to get data from FaunaDBq
is the instance offaunadb.query
Delete
is the FaunaDB delete method to delete entries from a collectionRef
is the unique FaunaDB ref used to identify the entryCollection
is area in the database where the data is storedIf you’ve hard coded a
commentId
you can now run the following in your CLI:If you head back over to COLLECTIONS in FaunaDB you should see that entry no longer exists in collection
Indexes
Next you’re going to create an INDEX in FaunaDB.
An INDEX allows you to query the database with a specific term and define a specific data shape to return.
When working with GraphQL and / or TypeScript this is really powerful because you can use FaunaDB indexes to return only the data you need and in a predictable shape. This makes data typing responses in GraphQL and / TypeScript a dream… I’ve worked on a number of applications that just return a massive object of useless values which will inevitably cause bugs in your app. blurg!
get-all-comments
As mentioned above when you query the database using this index you can tell FaunaDB which parts of the entry you want to return.
You can do this by adding “values” but be careful to enter the values exactly as they appear below because (on the FaunaDB free tier) you can’t amend these after you’ve created them so if there’s a mistake you’ll have to delete the index and start again… bummer!
The values you need to add are as follows:
ref
data.isApproved
data.slug
data.date
data.name
data.comment
After you’ve added all the values you can click SAVE.
Get all comments
The breakdown of this function is as follows
client
is the FaunaDB client instancequery
is a method to get data from FaunaDBq
is the instance offaunadb.query
Paginate
paginates the responsesMatch
returns matched resultsIndex
is the name of the Index you just createdThe shape of the returned result here is an array of the same shape you defined in the Index “values”
If you run the following you should see the list of all the comments you created earlier:
Get comments by slug
You’re going to take a similar approach as above but this time create a new Index that allows you to query FaunaDB in a different way. The key difference here is that when you
get-comments-by-slug
you’ll need to tell FaunaDB about this specific term and you can do this by addingdata.slug
to the Terms field.get-comments-by-slug
data.slug
in the terms fieldThe values you need to add are as follows:
ref
data.isApproved
data.slug
data.date
data.name
data.comment
After you’ve added all the values you can click SAVE.
The breakdown of this function is as follows:
client
is the FaunaDB client instancequery
is a method to get data from FaunaDBq
is the instance offaunadb.query
Paginate
paginates the responsesMatch
returns matched resultsIndex
is the name of the Index you just createdThe shape of the returned result here is an array of the same shape you defined in the Index “values” you can create this shape in the same way you did above and be sure to add a value for terms. Again be careful to enter these with care.
If you run the following you should see the list of all the comments you created earlier but for a specific
slug
:Approve comment by id
When you create a comment you manually set the
isApproved
value to false. This prevents the comment from being shown in the app until you approve it.You’ll now need to create a function to do this but you’ll need to hard-code a
commentId
. Use acommentId
from one of the comments you created earlier:The breakdown of this function is as follows:
client
is the FaunaDB client instancequery
is a method to get data from FaunaDBq
is the instance offaunadb.query
Update
is the FaundaDB method up update an entryRef
is the unique FaunaDB ref used to identify the entryCollection
is area in the database where the data is storedIf you’ve hard coded a
commentId
you can now run the following in your CLI:If you run the
getCommentsBySlug
again you should now see theisApproved
status of the entry you hard-coded thecommentId
for will have changed totrue
.These are all the operations required to manage the data from the app.
In the repo if you have a look at
apollo-graphql.js
which can be found infunctions/apollo-graphql
you’ll see the all of the above operations. As mentioned before the hard-coded values are replaced byargs
, these are the values passed in from various parts of the app.Netlify
Assuming you’ve completed the Netlify sign up process or already have an account with Netlify you can now push the demo app to your GitHub account.
To do this you’ll need to have initialize git locally, added a remote and have pushed the demo repo upstream before proceeding.
You should now be able to link the repo up to Netlify’s Continuous Deployment.
If you click the “New site from Git” button on the Netlify dashboard you can authorize access to your GitHub account and select the
gatsby-fauna-comments
repo to enable Netlify’s Continuous Deployment. You’ll need to have deployed at least once so that we have a pubic URL of your app.The URL will look something like this
https://ecstatic-lewin-b1bd17.netlify.app
but feel free to rename it and make a note of the URL as you’ll need it for the Netlify Identity step mentioned shortly.Environment Variables Pt. 2
In a previous step you added the FaunaDB database secret key and collection name to your
.env
files(s). You’ll also need to add the same to Netlify’s Environment variables.Proceed to add the following:
While you’re here you’ll also need to amend the Sensitive variable policy, select Deploy without restrictions
Netlify Identity Widget
I mentioned before that when a comment is created the
isApproved
value is set tofalse
, this prevents comments from appearing on blog posts until you (the admin) have approved them. In order to become admin you’ll need to create an identity.You can achieve this by using the Netlify Identity Widget.
If you’ve completed the Continuous Deployment step above you can navigate to the Identity page from the Netlify navigation.
You wont see any users in here just yet so lets use the app to connect the dots, but before you do that make sure you click Enable Identity
Before you continue I just want to point out you’ll be using
netlify dev
instead ofgatsby develop
oryarn develop
from now on. This is because you’ll be using some “special” Netlify methods in the app and staring the server usingnetlify dev
is required to spin up various processes you’ll be using.netlify dev
http://localhost:8888/admin/
You will also need to point the Netlify Identity widget at your newly deployed app URL. This was the URL I mentioned you’ll need to make a note of earlier, if you’ve not renamed your app it’ll look something like this
https://ecstatic-lewin-b1bd17.netlify.app/
There will be a prompt in the pop up window to Set site’s URL.You can now complete the necessary sign up steps.
After sign up you’ll get an email asking you to confirm you identity and once that’s completed refresh the Identity page in Netlify and you should see yourself as a user.
It’s now login time, but before you do this find
Identity.js
insrc/components
and temporarily un-comment theconsole.log()
on line 14. This will log the Netlify Identity user object to the console.netlify dev
If this all works you should be able to see a console log for
netlifyIdentity.currentUser:
find theid
key and copy the value.Set this as the value for
GATSBY_ADMIN_ID =
in both.env.production
and.env.development
You can now safely remove the
console.log()
on line 14 inIdentity.js
or just comment it out again.…and finally
netlify dev
Now you should be able to login as “Admin”… hooray!
Navigate to
http://localhost:8888/admin/
and Login.It’s important to note here you’ll be using
localhost:8888
for development now and NOTlocalhost:8000
which is more common with Gatsby developmentBefore you test this in the deployed environment make sure you go back to Netlify’s Environment variables and add your Netlify Identity user
id
to the Environment variables!Proceed to add the following:
If you have a play around with the app and enter a few comments on each of the posts then navigate back to Admin page you can choose to either approve or delete the comments.
Naturally only approved comments will be displayed on any given post and deleted ones are gone forever.
If you’ve used this tutorial for your project I’d love to hear from you at @pauliescanlon.
By Paulie Scanlon (@pauliescanlon), Front End React UI Developer / UX Engineer: After all is said and done, structure + order = fun.
Visit Paulie’s Blog at: www.paulie.dev
The post Roll Your Own Comments With Gatsby and FaunaDB appeared first on CSS-Tricks.
CSS-Tricks