DEV Community: Stephen Fluin

I give up on AngularFire

Stephen Fluin — Sat, 25 May 2024 21:56:09 +0000

I just worked really hard to rip AngularFire (@angular/fire) out of my codebase.

If you don't know, AngularFire used to be awesome. This was best around 2019-2020, but after being under-served and failing to fully finish several migrations (the Firebase SDK now uses a modular approach), it's kind of a mess.

I tried and failed to update from v6 up to v16, v17, and beyond, because I wanted to use Angular 18. This didn't work (ng update would refuse to update to v16 because it forces only updating one major at a time, which is a bit silly), so I ended up deciding to rip it out.

Steps to remove

Remove @angular/fire from your package.json
Swap out the AngularFireModulesfor your own keys

providers: [
  { provide: BUCKET, useValue: '...'},
  { provide: FIREBASE_APP, useFactory: () => initializeApp({...})}

Create a service that calls initializeApp from firebase/app and save yourFirebaseApp.constructor(@Inject(FIREBASE_APP) private fbApp: FirebaseApp) {`
Create (or use the same) a service for each of the Firebase modules you want to use, and then get a persistent handle on the service you want. typescript db = getDatabase(this.fbApp); storage = getStorage(this.fbApp); auth = getAuth(this.fbApp);

Here's the commit on the fluin.io repo.

Introduction to i18n for Angular

Stephen Fluin — Sun, 08 Dec 2019 07:46:28 +0000

This article was written for version 9.0 of Angular or later

English is the most common language for the web, but if you ignore other languages and locales, you're missing out on 80% of the planet. In my experience at companies like Trello and Google, I saw first hand that localization (l10n) and internationalization (i18n) can be a competitive advantage.

Supporting customers in other regions by understanding their language and expectations can have great rewards. Every user prefers an application that treats you like a first class citizen?

I18n in Angular

Angular was built with internationalization in mind. There are built-in capabilities for localizing dates, currency, numbers, and more, but part of the magic comes from the declarative templates.

The way you build applications in Angular is to create a tree of components, each with an HTML template. In that template you'll see normal HTML, as well as custom Angular components.

In this intro, I'm going to momentarily ignore pipes and complexities like genders, plurals, and focus on the basics of i18n. There's an awesome full i18n guide on angular.io.

Step 1:`i18n` markers in elements

Angular has built-in support for translations and i18n as part of the template syntax.

Let's imagine we have a span and a my-component. Both are marked for internationalization the same way. Add what looks like an i18n attribute. This will be stripped away by the build.

<span i18n>Hello!</span>
<my-component i18n>Goodbye!<my-component>

For both of these, the i18n markers indicate that the strings within the tags should be translated.

Step 2:`i18n-X` markers in properties/attributes

Similarly we can mark properties/attributes for translation. Let's imagine a simple image.

<img alt="Hello world" i18n-alt src="my-image.jpg">

The i18n-alt marker indicates that the "alt" attribute should be translated.

Step 3: Install @angular/localize

Add a dependency on @angular/localize in your package.json. The version number should match the rest of the Angular framework packages

Step 4: Extract Strings

The CLI has the capability of extracting all of the marked strings into an industry-standard format, such as XLIFF.

ng xi18n

x18n refers to 'extract internationalization". This will render a new file located atsrc/messages.xlf. Open this messages file in a translation tool (eg Virtaal) or pass it to a translation house for translation.

What you should get back is a translated XLIFF file. Let's imagine I get back a french file and store it at src/messages.fr.xlf.

Step 5: Configure `angular.json`

As of 9.0 and Ivy, multiple translated builds can be quickly produced as part of the CLI's standard build process. This used to be really slow and somewhat manual.

Within your project key in angular.json, add an i18n key and specify the source locale and locales you would like translated, along with their translated XLIFF file. The original strings in this example were written in English (en-US), and the the new language is French (fr).

      "i18n": {
          "sourceLocale": "en-US",
          "locales": {
              "fr": "src/messages.fr.xlf"
          }
      }

You'll also have to set "localize" to true in your angular.json configuration options. This belongs, for example, within angular.json, look for/projects/my-project/architect/build/configurations/production/localize.

              "localize": true

Step 6: Run a build

Based on the newly configured angular.json file, every time you run a production build with ng build --prod, you'll get two (or more) folders in your /dist/ directory, one for each locale and the original locale.

With build-time i18n, there's NO performance overhead at runtime, as each set of static files is entirely dedicated to a single language. Runtime i18n, where messages are loaded as part of application bootstrap, will be made available in the future.

To see your site live, just host each version of the site in a different folder or different domain. This could be example.org/en-US/ and example.org/fr/, or it could be example.org and fr.example.org.

What to Do If You Are Trapped on Angular v4?

Stephen Fluin — Sat, 07 Dec 2019 07:39:34 +0000

This article is for anyone still on Angular versions 2.x, 4.x, or 5.x.

Since May of 2018 and the release of version 6.0, it's been easy to stay up to date with Angular. That was the release where the CLI, framework, and material packages were all synchronized on their major versions. The 6.0 release introduced a version of ng update that would automatically migrate your applications, keeping them up to date by using Schematics.

If you are on version 6 or later, you get all of these benefits, but what if your application is on version 5, 4, or 2? You could manually move from 2->4 by updating your package.json, then move from 4->5 the same way. You could finally use the 6.0 CLI version of ng update to move to 6.0, but this isn't my recommendation.

Start from scratch

My core recommendation is to start from scratch. Not restarting your code (components, modules, etc), but only the build system and other files that the Angular CLI creates. This includes things like polyfills.ts, tsconfig.json files, your angular.json (formerly angular-cli.json) and other build configuration.

Step 1: Start a new CLI project

Since we're starting from scratch, let's start with the latest version of Angular. You can either install it globally, or just run:

npx @angular/cli new my-new-app

This will create a blank project, following all of the latest and greatest best practices.

Step 2: Migrate your application code

You should basically be able to copy and paste all of your TypeScript code from your src/app folder into the new src/app folder.

This should virtually work out of the box, but you should double-check things at this point. open VS Code and look for errors and make sure the major functionality of your app works.

If you have any dependencies, you'll have to add them back into your package.json.

Step 3: Fix any Angular changes

Versions 4, 5, 6, 7, 8, and 9 don't include a ton of breaking changes, but there's a chance that something isn't compatible.

Take a look at update.angular.io and see the list of changes that have happened within Angular. This should give you some high-level guidance for fixing anything that might have changed.

Step 4: Migrate your assets and other files

Now that the application works, make it complete by migrating assets, favicons, and anything else that you might have to update pointers for in your angular.json file.

Step 5: Double-check everything

At this point, you should be all set. There might be some final cleanup necessary. Things like dependencies should be updated. Make sure your linting and end to end tests work.

Step 6: Fix your git history

This is a little bit complex, but I recommend blowing away the my-new-app git configuration located in .git and then copy the .git folder from the old project.

When you run git status, you should be able to run git add . to stage a large single diff, moving your application from your old version to the new version of Angular. Then you can git commit and finalize and push the changes back to your repository.

Host Your Angular Project With GitHub

Stephen Fluin — Fri, 06 Dec 2019 06:36:06 +0000

GitHub is one of the central places that developers go to share, collaborate, and host the code for their projects. One of the most overlooked capabilities of GitHub is that since all the way back in 2009, GitHub has offered really simple free hosting for web applications to let users access the built version of your app.

Normally to use GitHub hosting, you'd setup a custom branch and commit and push static assets (and optionally Jekyll configuration). This was kind of a pain, and I think this was the main thing preventing most developers from using their hosting.

The Angular community and the new builders API have come to the rescue now though, and it's almost trivial to setup and use GitHub pages for hosting your small Angular App.

Usage Limits

This isn't for everyone, but their limits are pretty high. Their limits include:

1GB of disk space - I've NEVER seen an Angular app need this much storage, typically big files go in a backend or bucket or cloud storage)
100GB of bandwidth per month - If your app is 6MB (which is crazy high, but pretty normal), you could host an app with 25,000 monthly visits
10 builds per hour - I think we'll be okay :)

So while we couldn't host angular.io on there, I'd argue there are hundreds of thousands of apps that could be hosted just fine on GitHub.

How to deploy to GitHub pages in Angular

To do this we're going to configure a new dependency in our project with ng add. This new dependency is going to setup a builder that will do all of the heavy lifting for us.

These steps already assume you have Git setup and connected to your origin on GitHub.

Simply run the following in your app to set it up:

ng add angular-cli-ghpages

That's it. Now to actually do the build and deploy:

ng deploy --base-href=REPOSITORY

The base-href option makes it so the application can work when being served from that subdirectory. This will cause a path like /about to resolve to /REPOSITORY/about, which is what you want.

Your site will now be live at https://USERNAME.github.io/REPOSITORY/ (eg https://stephenfluin.github.io/angular-minesweeper/ )

Back in my day we had to deploy by walking 14 miles in the snow, uphill both ways. You whippersnappers have it so easy.

Running the deploy command will trigger several steps: the builder will initiate a production build, commit only the results into the gh-pages branch, and push it up to GitHub. Your app will be live instantly.

Make it awesome

To really make your app shine, you should probably move it to a custom domain name. Let's give that a try.

Open the settings for the repository.

Now scroll down to the "GitHub Pages" section. This is where the controls are for setting up the branch the site is hosted from. You'll only need to customize the "Custom domain" section.

Enter a domain like app.mydomain.com, then go and create the records in your DNS provider. You'll need to create a CNAME record pointing at USERNAME.github.io, and things should just work.

Want to make it ever better? You'll want a bare custom domain; this is when you want to host without a subdomain. These are called apex domains by GitHub.

To do this, you'll change the repository's GitHub Pages setting to the new domain, and then setup A records pointing at 185.199.108.153, 185.199.109.153, 185.199.110.153, and 185.199.111.153.

Is My Angular Performance Normal?

Stephen Fluin — Thu, 05 Dec 2019 03:44:21 +0000

One of the most common things I do when encountering a new Angular app or team, is to take a look at their application in DevTools. There isn't a ton you can do to see the underlying code or architecture, but there's a a couple things you can do.

You can check to see what version of Angular they are using. Just search for ng-version in the elements tab. You could also just have installed my Angular Inspector extension.

The other thing you can do is to see how big and fast the application is. Just switch over to the network tab and look at how much your browser has to download to run and display the first page of an application. To me, this is one of the most important performance considerations as the initial load time of your users is almost entirely determined by your initial bundle size.

You could have as much code as you wanted if you lazy loaded it at the right time, and users would never know, but the initial load is what could cost you millions if your site is too slow for your users.

What's Normal?

Here's a few example Angular apps (from successful companies) that you can see in the wild and their inital bundle size as reported by DevTools:

Delta.com: 4.2MB
Forbes.com: 5.7MB
Android Messages: 1.1MB
Grubhub: 3.4MB

For comparison, here's some non-Angular JavaScript bundle sizes:

microsoft.com is 1.4MB
amazon.com is 7.5MB
theverge.com is 9.6MB
Wikipedia pages are 223KB
reddit.com is 4.9MB
netflix.com is 4.2MB (for logged in users)
twitter.com is 3.5MB

Keep in mind that for some of these, it's not as bad as it sounds. Server side rendering or prerendering can mean that a lot of this JS is not in the critical path for page rendering, which is one GREAT way to partially get around initial JS size. Some of these also conditionally serve JS based on heuristics about anticipated user activity, which is another great strategy. Serving different bundles to different user types (fast network, slow network, powerful device, slow device) is also another advanced strategy that will change these numbers.

Looking at how big the top web properties are getting today... Yeah, your app is probably normal. But is that who you want to be?

Normal is not good enough

It's worth noting that the moment you start pushing past a few hundred kilobytes, your users (especially on mobile) are going to have to start to wait for you. Waiting kills user experience, it kills engagement, it kills sales.

If you used almost every single feature of Angular on your home page, including browser animations, forms, the router, http, and some Angular Material components (by the way, don't load everything on your home page), but wrote no code yourself, your entire application would be less than 400kb, which means that any time your application exceeds 800 or 900kb, it's because you are asking your users to run lots of your code to generate your pages.

If you look at the coverage report available in the bottom pane, the situation is almost dismal. Most of the time, LESS than 50% of the JavaScript sent down with a page is executed on initial load. A bunch of this code is for is error handling, and some of it can be Angular's fault, but a lot of the unused JavaScript comes from us just not being aware of the problem.

FYI this blog is about 482KB today, and sometimes benefits from prerendering.

The Main Culprits

How does this happen? How do we go from a blank application with all of the platform features at 400KB to a real application in the several megabytes range? The most common cause is marketing and advertising tools. Everything from your analytics package, to your user tracking, to your help desk tools can end up costing your usres and harming user experience, when they were built to try to help.

Here's some of the top offenders I've seen polluting bundle size and performance:

SiteCatalyst
fbevents
ruxit
LivePerson

There are hundreds more, but these are ones that I've seen multiple times when inspecting large applications.

What do I do?

Decide when, where, and how you want to set the balance between user experience, load performance, customer engagement, and intelligence.

Analyze your bundles ruthlessly. Generate source maps for every chunk and every bundle, and look to see what's in them? I recommend source-map-explorer. Don't be afraid to ask why you are making your users pay for certain features, capabilities, and dependencies.

If you really want a single button a user can press to get a live person, why not separate the actual functionality into a lazy route, and only render the button until a user requests it?

Hopefully this post has made you feel better and worse at the same time. If you have small bundles, congratulations! Keep it up! If you have large bundles, you're probably in good company, but we all need to strive to do better for our users.

State of Angular Design Tools

Stephen Fluin — Wed, 04 Dec 2019 06:28:44 +0000

In 2018 I gave a talk titled "Angular for Designers". It's been one of the talks that I get asked about most often, so I want to give an update.

In the talk, I lay out that the Angular team cares about designers, this is true! A lot of the simplifications to Angular over the last couple of years have been focused on making it easier for anyone to pick up and go with Angular, but beyond the changes within Angular, the ecosytem has been doing an awesome job of rising to this challenge.

Here are a few of the tools out that that might be interesting to those of us with a design slant.

Ionic Studio

I consider the direction Ionic Studio is headed to be the closest thing to "unified design and development". The ionic team are working on enabling designers to load existing projects and create new ones in a way that will keep working after development has begun.

By getting rid of the handoff step from design to development, it enables both Designers and Developers to take advantage of each others tooling and to grow their skillsets, it creates more collaboration across the lifetime of a project, and it means that you don't have the churn of going back and forth reproducing similar work when the direction changes from one team or another.

This is a paid tool.

Angular Console & VS Code

Not a fan of running terminal commands, but want to get comfortable with Angular? Angular Console is a great tool from the folks over at Narhwal that wraps the Angular CLI with a bunch of simple GUI interfaces that allow you to create, scale, serve, and build individual Angular projects and libraries.

This is a free tool.

UI Bakery

A paid tool from the folks at Nebular, they are trying to solve the challenge of giving designers a WYSIWYG editor that can use their Nebular component library to design real Angular apps and components.

At any time, you can hit the "get code" button to export your project to a real Angular CLI project, giving you a very strong jumping off point for development, and giving designers the ability to design within the bounds of HTML/CSS/Componentry.

This is a paid service.

Indigo Design

If you like the Indigo component library, they actually give you Sketch componentry that you can use to create realistic mockups. The magic for Indigo is that they have a web based code generation service that will take the components you assemble in sketch and it will spit out an Angular CLI project.

Design in sketch with their components, get a real project.

This is a paid service.

Codesign

The Google-built tool I mentioned (and has sinced been shared more broadly at other conferences) is currently called Codesign, and right now it's internal to Google, so external folks can't access it. The Codesign folks are hoping to do a public launch at some point in the future, but they don't have a timeline.

Codesign is really good at dragging and dropping components and has a fantastic WYSIWYG editor. It has an internal data model that used to be HTML but isn't any more (designers didn't find it useful). The magic of codesign is in their ability to import other component libraries.

This tool is not released.

How to Give Great Technical Presentations

Stephen Fluin — Tue, 03 Dec 2019 06:35:43 +0000

I talk a lot. In 2018 I gave 45 presentations (many were recorded!) Most of my presentations are uniquely crafted for the topic, the event, and the audience I'm speaking to. I have also reviewed several hundred technical presentations for events I've been involved in. Here are some of the things I've learned along the way.

Understand Yourself

Every time I work with a speaker I ask the most important question of all:

"After my talk, what do I want my audience to think/feel/do?"

This is the most important question because it gets at the WHY of your presentation. If you don't have a WHY or a goal, then there's no world where you can be successful.

For some folks, this is "inspire the audience to try my technology", which is okay, but can come across a little salesy. Often times talks like "build faster applications" or "start a conversation with their neighbor about X" or "can be far more impactful.

Remember that human beings almost never change their behavior, so keeping your goal in mind and keeping all of the points and topics you cover connected to your central mission will help drive the right outcomes.

Understand Your Audience

Who are you speaking to? Are you speaking to a homogenous crowd of experts who have the same frame of reference as you? NO! This never has and never will be the case.

You should seek to put yourself in the shoes of your audience before you write your talk, to make sure you are sharing something that is of value to them in a way that makes sense. You should ask yourself at least the following questions:

Are there subgroups among this audience, like beginners and experts that might want different content? How do I balance between these groups?
What assumptions am I making in this talk that might be different from the perspective of the audience?
What are the other presentations or materials might this audience have seen?
What's the right pace for this audience?
How can I make my presentation stand out for this audience? More live coding or more funny cat gifs?

Tell a Story

Let me compare three ways of conveying information:

"Angular released 2.0 on September 14th, 2019."

"The Angular team held a big party in September 2019 to celebrate a moment they had been waiting for, the 2.0 release."

"In September 2019, Jules had this crazy idea to order a giant pack of balloons that we would drop from the ceiling as part of the 2.0 release of Angular. David East volunteered to pull the string, but when the time came live on stage, the bag wouldn't open, and David almost cut his hands trying to get it open in front of the live audience."

The first conveyed information, and the information is easily forgotten and the specifics don't really matter.

The second started to share a moment in time, but it's shared in an abstract way without humanity or personal connection.

The third shared a place, a time. You can picture David East at the front of the room fighting with the bag of balloons, and you're hundreds of times more likely to remember the story and connect emotionally to the feeling the team had during the 2.0 release of Angular.

Be a human and be yourself. Your audience will appreciate it.

Don't Read Slides

DO NOT READ SLIDES VERBATIM. If you were going to read to me your presentation, I'd much rather just have a download link. I can read slides faster than anyone can speak them. Even reading a script from speaker notes means that you're not going to be having an emotional connection to the audience. Everyone has different ways of accomplishing this, but my preferred technique has two parts:

Don't use speaker notes

My slides tell me the right stories to tell and the major points to hit. Find a point you can already talk about for 30-60 seconds, and make a simple slide that reminds you to hit that point.

User Fewer words on slides

I'll often start with a bullet point (bullet points can be boring, avoid them if you can) like: "Don't forget to update to the latest version" and then look at it again and slice it to say "update to the latest version" and hopefully end on something even shorter and simpler. like "stay up to date".

Keep It Short

Short talks are much easier than longer talks. If you have a choice, go for 20 minutes or less. It's far easier to keep an audience's attention for 20 minutes than to structure a talk for 60 minutes where you will inevitably end up speaking first thing in the morning or right after lunch, and you'll enter the battle of your life trying to keep the audience engaged.

Practice delivery

People are going to pay far more attention to the WAY you say things, than WHAT you say.

One of my favorite exercises to push you beyond your normal way of speaking and to increase your vocal variety is to grab a children's book and practice reading it. Read it through aloud a few times, and each time vary a different skill.

Pace - go really fast and then really slow
Volume - yell some words and sentences and whisper others
Pitch - high pitch like a tiny mouse, low pitch like a giant drum
Pauses - don't talk for 20 seconds between two sentences, and don't stop talking at all

The key here is EXTREMES. Go CRAZY! The further you take yourself out of your comfort zone, the more variety you'll end up adding to your actual talk.

Skip the Q&A

Some conferences love Q&A, but I recommend you reject it or don't leave time for it. Most of the time the questions you get are going to be poorly prepared, poorly explained, and only apply to a tiny subset of the audience. Instead you should make it clear how people can get a hold of you, or share their thoughts on your ideas.

Often times you'll need to change locations, so if you can say "meet me outside after the presentation if you want to get involved" this can be a great way to take control and build further engagement with your audience after the talk is done.

How to Become an Angular GDE

Stephen Fluin — Mon, 02 Dec 2019 17:55:48 +0000

Today, there are over 100 Angular Google Developer Experts (GDEs) across the globe. These folks are impactful for the community, well versed in the world of building great web experiences, and experts in the technologies that make up Angular.

We receive applications every day with new folks wanting to join the program, and this is one of the best parts of my job. Every week I get to meet new people that are passionate about sharing with, empowering, and engaging with others via technology. I get to meet people that are much smarter than me, and people that are building some of the coolest technology on the planet.

One of the toughest parts of my job is that there are literally thousands of people doing this at local meetups, regional events, and in local and online communities, but not everyone can be called a GDE. We save that designation for the TOP experts, who are pushing the limits of the technology, who are the best teachers and sharers, and those out there who are having the biggest impact on their communities.

To help those that think the Angular GDE designation might might be for them, I want to break down the criteria, the process, and give some general tips.

The Criteria

Every GDE is different. Some are heavy content-authors, writing viral content that engages and enlightens millions of developers. Others are speakers, presenting at the biggest tech events. Others are pushing new communities forward, creating events and opportunities for people to come together and collaborate.

In general, we're looking for people with accurate skills and knowledge about specific technologies like Angular and the web who combine this knowledge with great community impact and reach, leaving their mark on the world every month.

We generally look at Angular GDEs based on their activities in 5 categories (not all GDEs are active in all categories).

Speaking
Organizing
Content
Developing
Mentoring

We also look at your technology understanding and your ability to communicate about technology. You should be able to have a conversation and convey how you teach and explain Angular concepts, and show you have the technical grounding necessary to represent the technology.

The Process

Step 1: Be Awesome

Pretty simple, right? Not exactly. It can be hard to be heard above the cacophony of internet noise. It's hard to write blog posts that people want to read, it's hard to create repositories developers want to fork and learn from. It's hard to get accepted at top conferences. All of these things are hard to do, but you need to be doing really well in at least one of these to be considered.

Step 2: Get Referred

The easiest way to submit an application is to be referred by an existing GDE. If the program is currently accepting new candidates, a GDE referral should let you fill out an application. You should look through the criteria and determine that you are good fit before applying, because we ask for a lot of details and the application process can take a lot of time.

Step 3: Fill out a CV

The CV process has you sharing the metrics for your activities. You'll be asked to include links and evidence of your impact. This will be used throughout the process to measure and understand the awesome things you are doing for the community.

Step 4: Interviews & Checks

Once you have filled our your CV, you might get rejected right away, or you might be asked to do one or several interviews. These interviews typically cover a lot of what you put in your CV, as well as how you deal with interactions with the others, thoughts on current events. You'll be asked questions and opinions about technology and Angular. This is your opportunity to explain your impact, and show your expertise.

Step 5: Determination

Once you have made it through all of the checks and interviews, the full story of your activities will be reviewed again, and you'll receive a determination.

Typically if you have made it through several of the interviews but are rejected near the end, you'll be invited to try again in the future if your impact and skills look likely to continue to grow.

If you are accepted, welcome to the program!

Step 6: Maintain

GDE status is generally awarded yearly, so make sure you are continuing the awesome things that you were doing when you became a GDE.

Remember

The GDE program isn't currently doing enough to represent local communities around the globe . There are millions of developers in places like China, Russia, and India but we only have relatively few GDEs there compared to places where we have lots of GDEs, like in the US. We often have to consider different expectations based on different regions and cultural differences.

GDEs aren't only sharing technology with the world, they must be active listeners as well. We value a unique insight about technology or people far more than we value the act of taking existing concepts and explaining them to the world. We frequently ask our GDEs for thoughts and opinions on new APIs, and for feedback about our releases and efforts.

Finally, if you want to become a GDE because you think it will change your life and your career, you might be doing it for the wrong reason. We like to say that we don't create GDEs, we merely recognize them.

5 Things to Do After `ng new`

Stephen Fluin — Tue, 20 Aug 2019 17:48:08 +0000

The Angular CLI is the recommended approach for starting new Angular applications, because it gives you an awesome app out of the box. But let's imagine you've run ng new already. What should you do next? How can you help ensure you build an awesome app that scales?

For the purposes of this article, I'm going to assume you already chose to use SCSS and the router when prompted, because both of those are very good ideas.

1. Setup naive continuous integration with CircleCI

I call this a naive configuration, because it's not truly "continuous integration" until you have a much more robust system, but it's been a great starting point for applications I've worked on. I used to use TravisCI but it looks like the world is moving towards CircleCI.

Create a file called .circleci/config.yml

If you know how to configure CircleCI, great! Go ahead and do that. If you don't? Just use my most basic config here:

version: 2
jobs:
  build:
    working_directory: ~/my-project
    docker:
      - image: circleci/node:12-browsers
    steps:
      - checkout
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install --frozen-lockfile
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
      - run: xvfb-run -a npm run lint
      - run: xvfb-run -a npm run build --prod --progress=false

This config will automatically lint your project, and run a production build. It assumes you want Node 12, and to use yarn.

Why not run tests? You should probably run your tests too! I don't include them here because I have found that at least on day 1 of a new project, maintaining tests can often be a distraction from figuring out how your application should be architected, but every app should ALWAYS pass lint checks, and be buildable.

2. Add a design system

The easiest way to start making your app look better is to add a design system like Material Design. The Angular team provides a set of components that embody Material Design in the library Angular Material. You can add it into your app via the CLI, and then create a navigation component for your app.

ng add @angular/material
ng generate @angular/material:nav app-nav

This will create an app-nav component with many of the features you'll need to start your app in the right direction, from a responsive sidenav to a top toolbar.

3. Add offline support and PWA superpowers

Offline support is a really desirable feature in web applications that can make your app much more capable than traditional web apps. Angular's Progressive Web App (PWA) support makes this much easier.

ng add @angular/pwa

Running this command will create a web app manifest (manifest.webmanifest) which you should customize along with your favicon.ico and icons files. It also creates an ngsw-config.json which configures how your application should behave offline. Which files should be cached, when should they be cached (lazy vs prefetch)? Should you prefer the latest content (freshness) or the fastest content (performance) for a strategy.

Read all about the various options for the service worker config.

4. Add Firebase Authentication

Almost every application I've ever built needed to know something about my users, and to offer customizations and data for them over time. Often this leads us to build custom auth systems, or manually integrate with Google, Facebook, etc. Firebase gives us a better way. A single integration with Firebase's auth system means we can get access to all of the social logins we need, and we never have to manage passwords, and eliminates much of the worry over the security of our users.

ng add @angular/fire

You'll want to create a Firebase project on the console and add a Web App. It will give you a screen with a configuration that will look like this:

Ignore the instructions and copy the JSON configuration object. You'll place this in your app module as follows:

imports: [
...
AngularFireModule.forRoot({.. THE COPIED OBJECT...}),
...
]

From there I typically create some sort of auth.service.ts that wraps the Firebase authentication methods and provides helpful Observables I use throughout my app like "is the user currently logged in?"


this.isUser = auth.authState.pipe(map(authState => (authState ? authState.uid : null)));

5. Add a server & backend

This one is newer, but very cool. When you get big enough, you might start reaching for more traditional database tools like Mongo/MySQL/PostgreSQL, and when you want to take full control of your backend, it's possible to do so in the same Angular project via a cool framework called NestJS.

ng add @nestjs/ng-universal

This one command will update your Angular application with a server folder where you can nest generate new APIs or backend tools, and also adds in built-in server side rendering, which can improve the feeling of speed in your application.

Single Component Angular Apps

Stephen Fluin — Thu, 04 Jul 2019 02:44:29 +0000

The Angular documentation outlines best practices and patterns that most developers will need when creating large scalable applications.

But what if there were a whole class of apps that didn't need this power and flexibility? I call these Single Component Apps, and I build them every day.

Here's two examples that I built or worked on recently:

update.angular.io - the interactive Angular update guide
baby.fluin.io - an app I built for tracking my infant son

I'm also working on several others (like my Hex grid game) that will ship eventually.

How they work

Generally I have a single template with a lot of containers and divs that look like this: <ng-container *ngIf="data | async as result">. With ng-template, ng-container, and a liberal use of *ngIf and *ngFor, you can probably build most single screen applications.

Ignoring parts of Angular

Each of these applications uses a single component, meaning it's ignoring huge swaths of the Angular API.

I can use any of the features I want, but I don't feel compelled to use them until they make sense. This helps me avoid over engineering. I can naturally create services, pipes, queries only when I feel the need, creating an application that I can iterate quickly on in the beginning.

Better than Vanilla JS

These apps aren't sophisticated, and I could have built them with Vanilla JS, but then I would be writing a custom DOM manipulation / rendering methods, when the look and feel of a declarative template really meets my needs and make sense to me.

Angular is valuable in these apps due to the template syntax, change detection, pipes. It's also valuable simply due to the awesome build system that you get out of the box with the Angular CLI. TypeScript, minification/uglification, great live reload, and more all come by default.

But why not use multiple components?

If you need multiple components, go for it! As each of these applications grow, I expect I will eventually want to extract out some of my rendering logic and in the long run, components are fantastic for isolating parts of your application and making your code more reusable, and easier to reason able.

I generally like to start with a single component until its template violates DRY principles, or until it starts being a couple hundred lines of code.

If I ever want routing in these apps, I'll also go for components, as the Angular Router is wired for this functionality out of the box. Additionally, file level separation between routes is very logical.

Feel free to disagree

Don't like single component apps? That's okay! Most of these apps have a single developer, meaning they face very different challenges than any true enterprise or scaled app. But I think that we need to acknowledge that a lot of the apps we all write look like this, or at least start like this. By acknowledging they exist and look like this for a valid reason, maybe we create space where writing this type of app is OK.

The Differences Between function and Arrow Functions

Stephen Fluin — Wed, 19 Jun 2019 16:32:19 +0000

I was asked the difference between a classical function and the new modern arrow function syntax, but it's a little bit hard to explain without examples, so here's the two major differences.

Let's imagine we have a class called Data, and let's imperatively create two functions.

class Data {
    saveFunction;

    constructor() {
        // Classic Function
        this.saveFunction = function (data) {
            // save my data
        }
        // Arrow Function
        this.saveFunction = (data) => {
            // save my data
        }

    }
}

These two look identical, but let's dig into the two major differences.

Syntax Differences

So first of all, modern one is shorter, hurray! There's even a bunch of shorthand you can use, such as dropping the parentheses when you have only one parameter, and dropping the curly brackets when you want to return the results of a single expression.

These syntax differences become EXTREMELY useful when you start passing functions around, which happens a lot when we write asynchronous code using Promises, Observables, or even when we need to write callbacks.

Consider the following two implementations. Both are trying to take a list and return the odd numbers.

Classic function style:

[1,2,3,4,5,6].filter(function(item) {
  return item % 2;
}

Arrow function style

[1,2,3,4,5,6].filter(item => item % 2);

The lack of parentheses and the automatic return of the value of the expression really help cut down the length here.

The brevity increases the clarity of what's going on, once you know how arrow functions work.

Semantic Differences

There's one more important difference, which is that arrow functions and classical functions actually work slightly different. Classic functions create an "object" and a scope with its own definition of this, whereas arrow functions don't.

This becomes important in our original example, where we were creating functions inside of our Data class. Within classic functions, this probably don't refer to the instance you were probably expecting, but arrow functions do.

We can see this by popping the following code is an ES5 transpiler and looking at the classic JavaScript.

class Data {
    saveFunction;
    currentValue;

    constructor() {
        // Classic Function
        this.saveFunction = function (data) {
            // save my data
            this.currentValue = {};

        }
        // Arrow Function
        this.saveFunction = (data) => {
            // save my data
            this.currentValue = {}
        }
    }
}

Using the transpiler on the TypeScript Playground we get the following ES5:

var Data = /** @class */ (function () {
    function Data() {
        var _this = this;
        // Classic Function
        this.saveFunction = function (data) {
            // save my data
            this.currentValue = {};
        };
        // Arrow Function
        this.saveFunction = function (data) {
            // save my data
            _this.currentValue = {};
        };
    }
    return Data;
}());

Because the modern version is using a specifically mapped _this that it creates, the call to this.currentValue does exactly what we expect, updating the property of the instance. In the classic function , it creates a new property on the function, which is quickly thrown away.