HTML preprocessors can make writing HTML more powerful or convenient. For instance, Markdown is designed to be easier to write and read for text documents and you could write a loop in Pug.
In CodePen, whatever you write in the HTML editor is what goes within the <body>
tags in a basic HTML5 template. So you don't have access to higher-up elements like the <html>
tag. If you want to add classes there that can affect the whole document, this is the place to do it.
In CodePen, whatever you write in the HTML editor is what goes within the <body>
tags in a basic HTML5 template. If you need things in the <head>
of the document, put that code here.
The resource you are linking to is using the 'http' protocol, which may not work when the browser is using https.
CSS preprocessors help make authoring CSS easier. All of them offer things like variables and mixins to provide convenient abstractions.
It's a common practice to apply CSS to a page that styles elements such that they are consistent across all browsers. We offer two of the most popular choices: normalize.css and a reset. Or, choose Neither and nothing will be applied.
To get the best cross-browser support, it is a common practice to apply vendor prefixes to CSS properties and values that require them to work. For instance -webkit-
or -moz-
.
We offer two popular choices: Autoprefixer (which processes your CSS server-side) and -prefix-free (which applies prefixes via a script, client-side).
Any URLs added here will be added as <link>
s in order, and before the CSS in the editor. You can use the CSS from another Pen by using its URL and the proper URL extension.
You can apply CSS to your Pen from any stylesheet on the web. Just put a URL to it here and we'll apply it, in the order you have them, before the CSS in the Pen itself.
You can also link to another Pen here (use the .css
URL Extension) and we'll pull the CSS from that Pen and include it. If it's using a matching preprocessor, use the appropriate URL Extension and we'll combine the code before preprocessing, so you can use the linked Pen as a true dependency.
JavaScript preprocessors can help make authoring JavaScript easier and more convenient.
Babel includes JSX processing.
Any URL's added here will be added as <script>
s in order, and run before the JavaScript in the editor. You can use the URL of any other Pen and it will include the JavaScript from that Pen.
You can apply a script from anywhere on the web to your Pen. Just put a URL to it here and we'll add it, in the order you have them, before the JavaScript in the Pen itself.
If the script you link to has the file extension of a preprocessor, we'll attempt to process it before applying.
You can also link to another Pen here, and we'll pull the JavaScript from that Pen and include it. If it's using a matching preprocessor, we'll combine the code before preprocessing, so you can use the linked Pen as a true dependency.
Search for and use JavaScript packages from npm here. By selecting a package, an import
statement will be added to the top of the JavaScript editor for this package.
Using packages here is powered by esm.sh, which makes packages from npm not only available on a CDN, but prepares them for native JavaScript ESM usage.
All packages are different, so refer to their docs for how they work.
If you're using React / ReactDOM, make sure to turn on Babel for the JSX processing.
If active, Pens will autosave every 30 seconds after being saved once.
If enabled, the preview panel updates automatically as you code. If disabled, use the "Run" button to update.
If enabled, your code will be formatted when you actively save your Pen. Note: your code becomes un-folded during formatting.
Visit your global Editor Settings.
<body>
<nav id="navbar">
<header>
<h1>Angular Developer Guide</h1>
</header>
<ul>
<li><a href="#Introduction" class="nav-link">Introduction</a></li>
<li><a href="#Angular_CLI" class="nav-link">Angular CLI</a></li>
<li><a href="#Modules" class="nav-link">Modules</a></li>
<li><a href="#Routing" class="nav-link">Routing</a></li>
<li><a href="#Components" class="nav-link">Components</a></li>
<li><a href="#State_Management" class="nav-link">State Management</a></li>
<li><a href="#Forms" class="nav-link">Forms</a></li>
<li><a href="#Styles" class="nav-link">Styles</a></li>
<li><a href="#I18n" class="nav-link">I18n</a></li>
<li><a href="#Libraries" class="nav-link">Libraries</a></li>
<li><a href="#Workers" class="nav-link">Workers</a></li>
<li><a href="#Testing" class="nav-link">Testing</a></li>
<li><a href="#Development_Setup" class="nav-link">Development Setup</a></li>
<li><a href="#Production_Setup" class="nav-link">Production setup</a></li>
<li><a href="#External_Tools" class="nav-link">External tools</a></li>
</ul>
</nav>
<main id="main-doc">
<section class="main-section" id="Introduction"><header>
<h2>Introduction</h2>
</header>
<p>The main goal of this guide is to help developers on common simple and complex use cases developing an application with Angular.</p>
<p>Is a <strong>very opinionated guide</strong> about best practices and the aim is at high level. This isn't a <em>from zero guide</em> nor an <em>API Reference</em>. <a href="https://angular.io" target="_blank">Official Angular documentation</a> will be referenced in such cases when some basic knowledge is needed.</p>
<section class="sub-section">
<h3>About Angular</h3>
<p>Angular is a web application develoment framework to be used for the Front-End. It was developed to run on Javascript. However it's desgined to be used in Typescript, and transpiled to Javascript or other targets.</p>
<p>
I say that it is a Web <strong>Application</strong> Framework for a reason.
If you want to create a mockup, a static website or a small app (small enough to be only maintained by you)
Angular will be an overkill and there are other frameworks out there that may fit your needs more accurately (like React for example).
</p>
<h4>Web Components vs Web Applications</h4>
<p>
Other frameworks like <strong>React</strong> are <em>Web Component Frameworks</em>, but <strong>Angular is a Web Application framework</strong>
because it comes with a sort of other tools (and opinions) that go far beyond Web Components.
</p>
<p>
Ok, Angular helps creating components, but:
</p>
<ul>
<li>You can't render a component outside Angular (before Ivy). <em>There is Angular Elements, but it still works inside Angular</em></li>
<li>It does a LOT of more things for you: building proccess handling, bundling, routing, lazy loading, platform agnostic rendering, tooling for state management, i18n handling, component prototyping</li>
</ul>
<p>So, we can say that Angular is a Web Component framework, <strong>but it also adds a lot of functionality that you are going to need for developing a full Web Application.</strong></p>
<p>In the end, if your application is big and serious enough, you are going to need this kind of tools. <strong>The difference is Angular has <em>made</em> the decision for you already.</strong></p>
<p>React for example started as a simple library for Front-End components, but now you can find a lot of tools in the React environment that suit the roles of the rest of parts of Angular (because in the end, you are going to need them).</p>
<p>That is why I say that Angular (as this guide) is very opinionated. You can review and decide what tool or strategy use for each situation and edge case, or go ahead with the solution more experienced developers proposed</p>
<p>This, however, isn't always a pro. Sometimes we need something more specific or handmade tailored.</p>
<p>Anyway, everything can be changed. The Angular team deeply though about it and they improve the framework with each release, so everything is abstracted enough to be replaced with custom parts when needed.</p>
<h4>What's inside Angular?</h4>
<p>So, let's take a quick look to what comes with Angular:</p>
<ul>
<li>Angular CLI</li>
<li>ngc - Ng Compiler (a wrapper around Typescript Compiler)</li>
<li>Webpack - Bundler</li>
<li>Zone.js - Asynchronus abstraction layer (asynchronus context provider, change detection, error handling)</li>
<li>RxJS - Observer pattern library/framework</li>
<li>Karma - Test runner</li>
<li>The Angular Core - Renderer2 and rest of abstractions</li>
<li>WIP?</li>
</ul>
<p>The Angular Core it's Angular itself, and it relays on RxJS for every reactive interaction, but besides that, any other part of the package could be changed to another tool.</p>
</section></section>
<section class="main-section" id="Angular_CLI"><header>
<h2>Angular CLI</h2>
</header>
<p>Ok, so we have a lot of different packages, libraries and tools being use there in Angular. How does it orchestrates them? Using the CLI.</p>
<p><strong>ng</strong> (Angular CLI) is the Angular's swiss army knife.</p>
<section class="sub-section">
<h3>Angular CLI anatomy</h3>
<p>Well, let's start describing it and its usage.</p>
<p>First of all, the Angular CLI is no more than the glue for other tools outside the Angular CLI and the dependencies of itself.</p>
<p>These dependencies are the real tools doing the job on the background. So we have something like this:</p>
<ul>
<li><strong>@angular/cli</strong> - Main package</li>
<li><strong>@schematics/angular</strong></li>
<li><strong>@schematics/update</strong></li>
<li><strong>@angular-devkit/core</strong></li>
<li><strong>@angular-devkit/architect</strong></li>
<li><strong>@angular-devkit/schematics</strong></li>
</ul>
<p>Let's start with the glue itself.</p>
<p><strong>@angular/cli</strong> handles the comands, default behaviors and the external tools used in the build/deploy process (Webpack, Karma, TsLint...). In summary, it handles our Angular Workspace and the automatic tasks run inside it.</p>
<p>Ok, quite straight forward isn't it?</p>
<p>
Then we have the packages that are part of the <strong>@schematics/*</strong> namespace.
These contain the default schematics provided by Angular Team, and used through the <strong>ng generate</strong> command.
</p>
<p>And the last part: <strong>@angular-devkit/*</strong></p>
<p>These packages are the engine powering Angular CLI on the background.</p>
<p><strong>@angular-devkit/core</strong>: Utility functions used by the rest of packages of @angular-devkit</p>
<p><strong>@angular-devkit/schematics</strong>: The engine for creating code from schematics.</p>
<p><strong>@angular-devkit/architect</strong>: Engine for complex build tools (we'll see it more in-depth later).</p>
</section>
<section class="sub-section">
<h3>Angular CLI Key Concepts</h3>
<h4>Angular Workspace</h4>
<p>So, I've said that Angular CLI is the handler of your Angular Workspace, but what is exactly the worksapce and what does this mean?</p>
<p>Simplifying A LOT, the workspace is the root folder of your Angular project. Well, at least if you create it via <strong>ng new</strong> (using the Angular CLI).</p>
<p>This folder contains every file needed by the Angular CLI to run any operation over the project, from creating code to deploying the application.</p>
<p>You can find the official definition of <a href="https://angular.io/guide/glossary#workspace" target="_blank">what is an Angular Workspace</a> on the Angular documentation glossary.</p>
<h4>Schematics</h4>
<p>Schematics are a series of scripts (usually contained in a library) that can be run to automate specific actions over the filesystem.</p>
<p>Their role is usually to generate code.</p>
<p>Angular CLI contains a set of default schematics used by its command ng generate</p>
<code>ng generate component shared/components/my-shared-component</code>
<p>Angular CLI comes with a variety of schematics to generate different kind of code: applications, components, services...</p>
<p>As we'll see later, you can also create your own schematics.</p>
<h4>Architects & Builders</h4>
<p>Architects & Builders are two concepts that work together for manage our code from Angular CLI</p>
<p>The builders do operations over our code (build the project, serve it, deploy it, run tests...). Each builder is normally related to a dedicated npm package performing a specific task.</p>
<p>The architects map between the CLI, the targets & the builders, and also allow to configure the builder for the specific target.</p>
<p>So, more or less, architects parse commands to determine the builder, the target and the additional configuration to be used, and then the builders do the real job.</p>
<h4>Angular.json</h4>
<p>The angular.json file is the file previously known as angular-cli.json</p>
<p>Here is where we link all the pieces of the workspace together so they can work.</p>
<p>All the configuration for the workspace, its projects, its architects and builders is defined in this file.</p>
</section>
<section class="sub-section">
<h3>Schematics</h3>
<p class="todo"><strong>TODO:</strong> Add here a specific technical description about the schematic and then a explained down-to-earth version of the same</p>
<h4>Schematics CLI</h4>
<p class="todo"><strong>TODO:</strong> Explain the Schematics CLI a little bit before showing the command.</p>
<p>To install the Schematics CLI we should run:</p>
<code>npm install -g @angular-devkit/schematics-cli</code>
<h4>Creating a Schematic</h4>
<p>We organize the schematics into collections, so we should create a Schematics Collection (a schematics project).</p>
<code>schematics blank --name=my-schematic</code>
<p>That will create a new schematic collection with a single schematic inside, named my-schematic</p>
<p>Then, we can add more schematics to the collection. Just move to the project folder and run:</p>
<code>schematics blank --name=-my-new-schematic</code>
<p class="todo"><strong>TODO:</strong> Explain the interface of a schematics, and what a tree is (the filesystem)</p>
<h4>Testing a Schematic</h4>
<p class="todo"><strong>TODO:</strong> Add here info about spec files and how to send params to the test of the schematics</p>
</section></section>
<section class="main-section" id="Modules"><header>
<h2>Modules</h2>
</header>
<section class="sub-section">
<h3>NgModules Anatomy</h3>
</section>
<section class="sub-section">
<h3>Modules Bootstrap Process</h3>
</section>
<section class="sub-section">
<h3>Modules Architecture</h3>
<p class="todo"><strong>TODO:</strong> Add broad introduction about the optimal architecture to then explain in detail each part.</p>
<h4>Feature modules & Lazy Loading</h4>
<p class="todo"><strong>TODO:</strong> Explain the benefits of the lazy loaded modules</p>
<p>To create a lazy-loaded module we run:</p>
<code>ng generate module my-module --route my-module --module app.module</code>
<h4>Shared Module</h4>
<p class="todo"><strong>TODO:</strong> Explain the reason for having a shared module.</p>
<p class="todo"><strong>TODO:</strong> Explain what to include in the shared module and what not.</p>
<p class="todo"><strong>TODO:</strong> Explain what to import, declare and export in, at, or from the shared module</p>
<p class="todo"><strong>TODO:</strong> Explain where to import the shared module and where not to.</p>
<h4>SCAM Modules</h4>
<p class="todo"><strong>TODO:</strong> Explain the overhead of the shared module and how to avoid it with SCAM modules</p>
<h4>Core Module</h4>
<p class="todo"><strong>TODO:</strong> Explain the singleton pattern and the reasons for creating a core module</p>
</section>
</section>
<section class="main-section" id="Routing"><header>
<h2>Routing</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <h3>The Router</h3>
<h3>Snapshots</h3>
<h3>Routing events</h3>
<h3>Guards</h3> --></section>
<section class="main-section" id="Components"><header>
<h2>Components</h2>
</header>
<section class="sub-section">
<h3>Container-Presentation Design Pattern</h3>
<p class="todo"><strong>TODO:</strong> Explain the reason to implement this pattern, and what happens if you don't</p>
<h4>Presentational Components</h4>
<p class="todo"><strong>TODO:</strong> Add an introduction about what is a presentational component</p>
<p class="todo"><strong>TODO:</strong> Explain how to implement it, what to include and what not to include</p>
<h4>Container Components</h4>
<p class="todo"><strong>TODO:</strong> Introduce the concept of container component and explain its role in the pattern</p>
<p class="todo"><strong>TODO:</strong> Explain what to do in the container component and what not to do. Also how to use the presentational components from here</p>
<p class="todo"><strong>TODO:</strong> Add use cases about what is part of the container component and what should deserve its own presentational component</p>
</section>
<section class="sub-section">
<h3>Change detection</h3>
<p class="todo"><strong>TODO:</strong> Explain the benefits of the On Push change detection strategy</p>
</section></section>
<section class="main-section" id="State_Management"><header>
<h2>State Management</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <h3>RxJS</h3>
<p></p>
<h3>NgRX</h3>
<p></p>
<h4>NgRX-data</h4>
<p></p>
<h3>Akita</h3>
<p></p>
<h3>Abstraction layer using the Facade Pattern</h3>
<p></p> --></section>
<section class="main-section" id="Forms"><header>
<h2>Forms</h2>
</header>
<p></p>
<h3>Template VS Reactive</h3>
<h3>Form validation</h3>
<h3>Form components libraries</h3>
<h3>Control Value Accessor Interface</h3>
<h3>Self-validating Sub-forms</h3></section>
<section class="main-section coming-soon" id="Styles"><header>
<h2>Styles</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <p></p>
<h3>About View Encapsulation</h3>
<h3>Using pre-CSS imports</h3> --></section>
<section class="main-section coming-soon" id="I18n"><header>
<h2>I18n</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <h3>Angular's Official I18n solution</h3>
<h3>Alternatives</h3>
<h3>Best approach</h3> --></section>
<section class="main-section coming-soon" id="Libraries"><header>
<h2>Libraries</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <h3>Using libraries</h3>
<p></p>
<h3>Creating libraries</h3>
<p></p>
<h3>Useful Third-Party libraries</h3>
<p></p> --></section>
<section class="main-section coming-soon" id="Workers"><header>
<h2>Workers</h2>
</header>
<p class="todo">Coming soon...</p></section>
<section class="main-section coming-soon" id="Testing"><header>
<h2>Testing</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <p></p>
<h3>Components unit testing</h3>
<p></p>
<h3>Styles testing using snapshots</h3>
<p></p>
<h3>Functional testing</h3>
<p></p> -->
</section>
<section class="main-section coming-soon" id="Development_Setup"><header>
<h2>Development Setup</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <h3>Local development scripts</h3>
<h3>Customizing linter</h3>
<h3>Proxy to the backend</h3>
<h3>Mocking the backend</h3> --></section>
<section class="main-section coming-soon" id="Production_Setup"><header>
<h2>Production Setup</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <p></p>
<h3>AoT Build</h3>
<p></p>
<h3>Proxy configuration</h3>
<p></p>
<h3>Server-side rendering</h3>
<p></p> --></section>
<section class="main-section coming-soon" id="External_Tools"><header>
<h2>External tools</h2>
</header>
<p class="todo">Coming soon...</p>
<!-- <h3>Command Line Tools</h3>
<h3>IDE Extensions</h3>
<h3>Browser Extensions</h3> --></section>
</main>
<script src="https://cdn.freecodecamp.org/testable-projects-fcc/v1/bundle.js"></script><div id="fcc_test_suite_wrapper" style="position: relative !important; z-index: 99999 !important;"></div>
body {
font-family: "Open Sans", Arial, sans-serif;
font-size: 16px;
background-color: #FAFAFF;
color: #151E3F;
display: flex;
flex-direction: row;
}
a {
color: #5E5C75;
}
nav {
min-width: 280px;
}
main {
max-height: calc(100vh - 20px);
width: 100%;
}
h2 {
font-size: 2rem;
text-decoration: underline;
}
h3, h4 {
color: #5E5C75;
}
h3 {
font-size: 1.4rem;
}
h4 {
font-size: 1.2rem;
}
section {
padding: 11px 0;
}
code {
padding: 8px;
background-color: #B6B6BA;
}
.todo {
background-color: rgb(228, 223, 163);
padding: 8px 6px;
}
@media(min-width: 768px) {
main {
padding-right: 256px;
}
h3, h4 {
color: #5E5C75;
}
h3 {
font-size: 1.8rem;
}
h4 {
font-size: 1.4rem;
}
}
Also see: Tab Triggers