[MUSIC PLAYING]
DAVID EAST: I'm going to show you
how to get started with Firebase for the web.
Now you might be using one of many different environments
or platforms.
You might use Angular, React, Vue, Svelte, or even plain
JavaScript.
No matter what you're using, I'm going
to teach you the fundamentals of including Firebase in your web
apps.
Now there are so many different ways of including Firebase
into your web app.
But in this video, we're going to use two key tools,
and that's NPM and a module bundler.
Now if you don't have NPM installed, don't worry.
Check the link in the show notes,
and you can install Node.js, which
automatically includes NPM.
But we're going to get started in four steps.
Step one, installing Firebase.
I'm in my editor, Visual Studio Code,
and I have my project open.
I'm going to use the terminal within VS Code
to run the command, npm init dash y,
to set up my NPM package.
Which, by the way, make sure to go back and fill out
all these fields in your package.json
with real information.
Then I'm going to install the Firebase SDK with "npm i
firebase."
Once the command finishes, you have access
to the Firebase library.
And this brings us to step two, creating a Firebase app.
I'm going to create a folder named src
and a file named index.js.
Then I'm going to write an import statement
that references the firebase/app subpackage.
From there, I'll import the initializeApp function.
This function creates a Firebase app
that stores your Firebase configuration for your project.
When you create a Firebase project in the Firebase
Console, we give you a configuration object
that you pass to this function.
And this function returns a Firebase app instance.
This instance is how the Firebase SDK
knows how to connect to your specific Firebase backend.
Now, I know what you're thinking.
What about this configuration object?
Isn't it unsafe to include this kind of information
on the client?
Can't someone take this info and delete all my data
in my database or something bad like that?
The Firebase configuration object is perfectly safe
to include on the client side.
It's how the Firebase library knows
how to talk to your Firebase project.
If you're worried about security-- which you should be,
so that's good--
you secure your Firebase projects
by using security rules and App Check.
If you want to learn more about those,
then check the links in the description.
But we're going to move on to step three, which
is importing Firebase services.
Let's say I want to monitor authentication states.
So I'll import Firebase Auth.
Now you might not be using Firebase Auth,
but don't worry, because it doesn't matter
what I'm using in this video.
Each Firebase service follows a similar pattern.
You import the service from its path, Firebase/service.
Then import the service getter function.
In this case, it's getAuth.
And, as you would expect, each subpackage
has a getter function.
If I was also using Firestore, then I
would follow a similar pattern.
What's important to note here is that you must initialize
your Firebase app first before calling any service getter
function.
Each getter function can optionally
take in the Firebase app as a parameter,
which I prefer to pass in, just to be explicit.
Now to use a feature like monitoring authentication
state, you import those as individual functions.
These individual functions take the Firebase service
as the first parameter.
The onAuthStateChanged function then
also takes a callback that tells me if a user is logged in.
This is the pattern that the Firebase SDK follows
for each subpackage as well.
Each function takes in an argument of either the service
returned from the getter function
or some relevant container object, like in Firestore.
If I want to create a collection,
I'll need to pass in the Firestore service
as the first parameter.
If I want to get the documents in this collection,
I can import the getDocs function,
and then pass the collection as the first parameter.
Now you might be wondering why these features are imported
as individual functions that take
in a service as the first parameter.
You might think that these functions
would be methods available on the service itself.
We actually had our older library structured that way,
but we learned over time that your web app can
get significant performance improvements by following
this functional approach.
Why?
Because when library code is structured
in this functional way, JavaScript module bundlers
know how to eliminate unused code.
And this is known as tree shaking.
It's extremely useful for reducing the amount of library
code in your application, which, in turn, will help speed up
page load performance.
Now we can't run this code as is in the browser,
because the browser doesn't understand these imports.
Now you might have seen in the documentation something called
browser modules.
Browser modules are a native web platform
feature that allow you to export and import code as modules.
I'm going to take these NPM paths
and convert them over to browser module paths,
and these are just what looks like links out
to a JavaScript file.
And what's great about these are is
that you can run these automatically in the browser.
So I'll add a index.html file and do
a simple little boilerplate.
And then in my head, I will reference the script.
And the important thing with browser modules
is to include the attribute, type equals module.
And now I'm just going to serve this directory.
And then here in the browser, we can
see that it says, "No user."
And when I click in, this is the exact code
that we have in our editor.
We provide examples for using browser modules because it's
really easy to get started.
You just copy the code, paste it into the browser,
and it just works.
But we don't recommend using them for production.
For production, we recommend module bundlers,
like webpack and Rollup.
And that's because there are so many optimizations that they
can do, just like tree shaking, which
will eliminate any unused code from the Firebase library.
Now, keep in mind, if you're using a framework CLI
tool like Angular CLI, Create React App, Vue CLI, Next.js,
SvelteKit, these tools, they handle the module bundling
for you.
They'll use a tool like webpack or Rollup underneath the hood.
So all the code that we've written so far
will just automatically get bundled for you in those tools.
But if you're doing this by hand,
or you just want to learn how it works with webpack,
then tune in to the last step.
Let's revert back to the NPM import path,
and then install webpack from NPM, but with two packages,
webpack and webpack CLI.
And we'll do the dash capital D flag to save it
as a development dependency.
And to use this, we'll tap into our node_modules folder,
then .bin, and then from here, we can use the webpack command.
The way that module bundlers work
is that they look for a file called an entry point.
This is the root of your JavaScript code,
and it usually imports everything
needed for the application.
And then dash o for an output folder of dist.
But, protip, if your entry point is located at src/index.js
and your output file needs to be dist/main.js,
then you can drop all of these flags.
So now we have our main.js file and our dist folder.
So I'm going to move over my index.html
and run the static server to check out the result.
And we see that we have "No user."
And then when I click on it, this file looks really strange.
But that's OK, because webpack is
going to do all sorts of optimizations that make
the final code look unreadable.
If you need to debug, you can always set up source maps.
So to set up source maps, I'm going
to create a configuration file for webpack named
webpack.config.js.
This can do some really advanced things like process
your TypeScript, copy files, start a dev server,
and all sorts of other things.
In this video, we're just going to set it up
to do some basic bundling.
Each webpack config exports out an object
that takes in a couple of required keys.
The first one is the entry property,
and this is the same thing as our dash dash entry flag.
So it's just our src/index.js.
Then the next thing it exports is the output key,
and this takes in two keys.
The first is the path, and the path
is the location of the folder.
And to specify this folder, we're
actually going to use a Node.js utility that
resolves to the folder.
And then it takes in the file name,
and that is the name of the bundle.
In this case, we'll name it bundle.js.
So the first step for the source map
is to set the mode to development.
And then finally, we'll set a devtool,
and this is how you specify your source maps.
Now there are all sorts of types of source map tools
you can provide, but we're going to use eval-source-map
because it is really readable.
I'm going to provide a link in the description
for all the other source maps you can use.
So now when we build, everything looks great,
and we can see that we have our bundle.js in the dist folder.
So now in index.html, I'm going to rename the file.
And when I run the server, no users on the console, and this
is the exact code we wrote in our editor.
And I can add breakpoints and step through it
as if it was the normal code that we wrote.
Drop a comment if you have any questions or an idea
for a fundamentals video.
And make sure to check out the Fundamentals playlist,
because it's brand new, but it's going to be growing with more
fundamental videos over time.
But that's the fundamentals of getting started
with Firebase for the web.
[MUSIC PLAYING]