React 18 Alpha With Snowpack and Vercel

Set Up React 18 Alpha With Snowpack and Vercel

React 18 Alpha With Snowpack and Vercel

If You Prefer Watching a Video…

Be sure to Subscribe to the Official Code Angle Youtube Channel for more videos.

Table of Contents

  1. Introduction
  2. Installation and Set up of React Using Snowpack
  3. Folder Structure
  4. Code Overview
  5. Running the Application
  6. Deployment Process Using Vercel
  7. Conclusion


Earlier this month the React Team released some updates concerning the release of React 18. These updates include the following:

  • Work has begun on the React 18 release, which will be the next major version.
  • A working group has been created to prepare the community for the gradual adoption of new features.
  • An Alpha version has already been published for library authors to try and provide valuable feedback.

This tutorial aims to set up the React 18 Alpha version using SnowPack, a lightning-fast front-end build tool, designed for the modern web. Then we deploy on Vercel.

Installation and Setup of React 18 Alpha Using Snowpack

First, you need to have Node.js installed, once that is done then you can now install Snowpack. You can use the command below to install Snowpack.

npm install snowpack

Once installed, you can head to a directory where you want to put your new project.

Now run the following command in your terminal to create a new directory called react-snowpack. This will automatically generate a minimal boiler plater template.

npx create-snowpack-app react-snowpack --template @snowpack/app-template-minimal

You can now head to the new directory with the following command:

cd react-snowpack

Once inside this directory, we can finally install the React 18 Alpha version by running the command below.

npm i react@alpha react-dom@alpha

Once this is done, you can check your package.json file to confirm React 18 Alpha has been installed. It should look something like what we have below.

  "dependencies": {
    "react": "^18.0.0-alpha-cb8afda18-20210708",
    "react-dom": "^18.0.0-alpha-cb8afda18-20210708"

Folder Restructure

React makes use of a templating language called JSX. JSX stands for JavaScript XML. It is an inline markup that looks like HTML that gets transformed to JavaScript at runtime.

The First step towards the folder restructure is to rename the index.js file with a jsx extension like so, index.jsx. Doing this will allow Snowpack to know that we are running a React project.

In the end, we should have the folder structure below.

> public
  > index.css
  > index.html
> src
  > App.jsx
  > index.jsx

Code Overview

We are going to have code modification in four files (index.html, App.jsx, index.jsx, and snowpack.config.mjs) before we start up the app and deploy it on Vercel.


<!DOCTYPE html>
<html lang="en">

  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <meta name="description" content="Starter Snowpack App" />
  <link rel="stylesheet" type="text/css" href="" />
  <title>Starter Snowpack App</title>

  <div id="root"></div>
  <script type="module" src="/dist/index.js"></script>


In the index.html code, three things have to be noted:

  • The id is called root which we will refer to in the index.jsx file.
  • In the script tag, we have a type called module to enable snowpack to know we will be making use of ES6 syntax.
  • Also in the script tag, we have an src attribute to signify the path of our deployment directory which will be configured in the snowpack.config.mjs file.


import React from "react";

function App() {
  return (
        <p>React 18 Alpha Setup Deployed on Vercel with SnowPack</p>
export default App;

Above in the app.jsx file, we generate a simple React boilerplate template using a functional component.


import React from "react";
import ReactDOM from "react-dom";
import App from "./App";

const rootElement = document.getElementById("root");
const root = ReactDOM.createRoot(rootElement);
root.render(<App />);

In the index.jsx file, we did three things to enable us startup the app.

  • First, we import React, ReactDOM, and the App.jsx file.
  • Then we created a variable to get the id in the index.html file.
  • Finally, we made use of the new createRoot API in React 18 to render the application.


/** @type {import("snowpack").SnowpackUserConfig } */
export default {
  mount: {
    /* ... */
    public: "",
    src: '/dist'
  plugins: [
    /* ... */
  routes: [
    /* Enable an SPA Fallback in development: */
    // {"match": "routes", "src": ".*", "dest": "/index.html"},
  optimize: {
    /* Example: Bundle your final build: */
    // "bundle": true,
  packageOptions: {
    /* ... */
  devOptions: {
    /* ... */
  buildOptions: {
    /* ... */

Every Snowpack app makes use of the snowpack.config.mjs file for any configurations like the deployment process. In this project, we will only edit the mount object by adding the public and src keys.

These serve as a pointer to the path where our deployment folder will be built when we run the build command.

Running the Application

Now with all our files saved, we can head back to our terminal and run the start command npm run start, which will produce the page below in the browser.

Application Running Screen in Browser

Now our React 18 alpha app is successfully up and running.

Deployment Process Using Vercel

“Vercel enables developers to host websites and web services that deploy instantly and scale automatically all without any configuration”. -Vercel Documentation

The first step towards deployment is running the command below at the root of our project.

npm run build

This will generate a build directory. Inside the build directory is a dist folder that contains the code we will push to Vercel.

Next up we do the following:

1. Install Vercel 

To do this we run the command npm i -g vercel

2. Log Into Vercel

After installing Vercel globally on your machine. Type vercel in the terminal. This will prompt you to log into your account if you are not already logged in.

3. Project Setup and DeploymentProject Setup and Deployment UI

To summarize the prompt question in the image above, the following questions will be asked:

Vercel will now build the application, installing all dependencies in the process. When the installation is done, a inspect link will be available in the terminal. With this link, we can access the Vercel dashboard to see our deployed app.

Deployed Application in Vercel Dashboard 

4. Open the Deployed Project

You can now visit the newly deployed project by clicking on the “visit” button on your dashboard shown in the image above.

Opening Deployed Project


You can find the deployed code in my GitHub account.

Source link

TreeTable Screenshot

Popular JavaScript TreeGrid Components for Productive Data M…

With the rapid advancement of information technologies, it is hard to imagine a business web application without the ability to present data in a tabular format. Every day business people are exposed to large amounts of information that may also require hierarchical division. Without using special tools such as a TreeGrid (also known as TreeTable), it can be very time-consuming to analyze big data sets and make the right decisions.

TreeGrid is a user interface element that helps to show complex data in rows and columns with expandable/collapsible nodes and enables users to interact with it. It combines qualities of standard DataGrid and Tree components. The main peculiarity of TreeGrid is that it allows you to group arrays of data hierarchically, thereby contributing to more convenient work with the given information. This functionality is highly demanded in financial and analytic systems, reporting tools, CRMs, etc.

If you are involved in creating interfaces for a business-oriented web solution, it will be helpful for you to read this article. Here you will become familiar with a collection of commercial JavaScript TreeGrid components that can be integrated into apps based on popular JavaScript frameworks and provide end-users with a variety of useful features for managing data.


DHTMLX TreeGrid is an easy-to-use JavaScript UI control designed for displaying big data in hierarchical tables of any complexity without performance limitations. It comes with a wide range of configuration options that serve to fine-tune all table elements to your needs. For instance, you can specify the size of your tree grid and adjust the height and width of columns to their content automatically, “freeze” columns, insert multiline content and custom HTML items in cells, and much more.

TreeTable Screenshot

This JavaScript TreeTable also allows working with numeric values of various formats and automatically performing calculations (min, max, average) in the table’s footer/header. If it is necessary to clarify any information in the tree table, you can apply custom tooltips. When talking about interactivity, end-users can manipulate data by selecting rows, resizing columns, moving rows and columns by drag-and-drop, sorting and filtering data, and via inline editing. It is also possible to work with table data offline after exporting it to Excel. It renders equally well on desktops and touch devices. The grid look is easily modified via CSS.

Easy to follow initialization process and TypeScript support help to make DHTMLX TreeGrid a part of your app much faster. This control is delivered in a bundle with other UI widgets included in the  DHTMLX Suite package or as a stand-alone component.

Trial version: DHTMLX TreeGrid

Price: from $509

Webix TreeTable

Webix TreeTable is a JavaScript widget with a responsive design that helps to arrange data in hierarchical tree-like structures. In fact, this tool encapsulates the properties and methods of two other Webix data management widgets (DataTable and Tree) and enhances their functional capabilities. It enables you to expand/collapse even entire tables. Thus, it is possible to compactly place many tables on a single page without resorting to pagination. 

Webix TreeTable works seamlessly with large amounts of multidimensional data thanks to dynamic loading. Multiple filtering and sorting options give users opportunities to quickly find required pieces of information in the table and, if necessary, edit them on the fly. Various selection and copy-paste modes make it much easier to borrow data from the table. The widget also allows utilizing math formulas and charts (Bar, Pie, Spline, etc.) in the grid. The list of available data exporting formats includes PDF, PNG, Excel. The documentation page provides more interesting details on the practical usage of this JS widget and its features.

Trial version: Webix

Price: from $849 (for a full package of UI widgets)

EJS TreeGrid

EJS TreeGrid is a DHTML component that provides different options for organizing data on an HTML page, including table, bar chart, grid, tree view, and as its name suggests a tree grid. Written in pure JavaScript, this component enables you to configure a tree table in accordance with your requirements and equip it with core functions typical for this kind of UI tool (sorting, filtering, grouping, searching). The tree table built with EJS TreeGrid can include any number of nesting levels in cells. The component supports various cell types, paging types, editing masks, and formatting values. 

EJS TreeGrid Screenshot

EJS TreeGrid also gives a chance to add some extra tools to the grid such as a Gantt chart, calendar, rich text editor. You can work with external objects like Flash Adobe or custom JS objects in the tree table. It is also possible to set animations for various TreeGrid actions. The tree grid interface can be adapted to various languages using the localization feature (including the RTL option for Middle East languages). The appearance of the tree grid is fully customizable via CSS styles. The table content can be saved to Excel or PDF format and printed if needed.  If you want to learn more details about EJS TreeGrid, check out the documentation section.

Trial version: EJS TreeGrid

Price: from $600


jqxTreeGrid is a part of the jQWidgets library used to lay out data utilizing a tree-like setup. This lightweight jQuery widget offers a range of core features with flexible configuration for manipulating data the way you need. Large volumes of data can be broken down into smaller parts for more convenient navigation using the paging feature. Load on Demand (also known as a virtual mode) is one more function that helps to ensure optimal performance with big data in tree grids. With this feature on board, child rows of the tree are generated and initialized only when the parent rows are opened. Other noteworthy features of this widget are pinned columns, aggregates, custom editors, cell formatting, custom cell rendering.

jqxTreeGrid Screenshot

jqxTreeGrid supports multiple data binding and exporting options. You can make the tree grid interface understandable to users from different countries by enabling various locales. Utilizing customizable default themes, you can create a unique design for your tree grid. If you want to test all capabilities of the jqxTreeGrid widget in practice, there is a special jsEditor tool.

Trial version: jQWidgets

Price: from $199 (for a full package of UI widgets)

Ignite UI Tree Grid

The Ignite UI library provides a number of UI components for the faster accomplishment of various web development goals, including hierarchical presentation of data. Two Ignite UI tools suit this purpose, namely – Hierarchical Grid and Tree Grid. Both grids are similar in terms of functionality, as they support the main features that are commonly expected from a grid component such as sorting, filtering, in-cell editing. But the Tree Grid is a more preferable option when building a table where the parent and child nodes have the same structure or if you want to offer end-users a simpler experience. 

Ignite UI TreeGrid Screenshot

Like in the case with jqxTreeGrid, good performance with large data sets is ensured by implementing pagination and Load on Demand features. Infragistics also equips developers with two online tools to facilitate the work with Ignite UI grid components. The HTML5 Page Designer tool helps to try Ignite UI widgets in action with simple drag-and-drop manipulations, while the Theme Generator allows tuning the look and feel of the tree grid to your liking. Online documentation will give you a clear idea of how to use the potential of this JS component to the maximum.

Trial version: Ignite UI

Price: from $849 (for a full package of UI widgets)

Syncfusion Tree Grid 

Syncfusion Tree Grid is a JavaScript control dedicated to presenting self-referential hierarchical data in the form of tables. It is one of the numerous ready-made UI components included in the Essential JS 2 library. This tool comes with a set of useful features that are crucial for effective data management such as sorting, filtering, editing, aggregations, stacked headers, etc. Thanks to the mobile-optimized design, Syncfusion-based tables are displayed well on devices with different resolutions and screen orientation. Using special templates, you can create custom grid elements (headers, toolbars, etc.). As for the tree grid appearance, Syncfusion provides not only a package of default themes but also the Theme Studio application for defining your own style. 

Syncfusion TreeGrid Screenshot

Data can be loaded in the table from local and remote sources (JSON, RESTful, OData, and WCF services). The control relies on several performance-related techniques. You can apply row virtualization and infinite scrolling to improve user experience with large bundles of data. In addition, it is also possible to enable the immutable mode that boosts the tree grid re-rendering performance. The control also supports localization and internationalization libraries that help to make the text content and date/number objects in the tree table understandable to users from different countries. If users require a hard copy of the information presented in the grid, export it in PDF, Excel, CSV formats. More details on Syncfusion Tree Grid and how to get started with it in real projects can be found on the documentation page.

Trial version: Syncfusion

Price: from $995 (for a full package of UI widgets)

Final words

Summarizing the above, we can say that a tree table is one of the most important and complex UI components that can be complemented with numerous features. Therefore, integrating this functionality in a web application from scratch seems like not the best decision, especially if you don’t have much time. In my opinion, it is more effective to use any of the reviewed JavaScript components. Which one to choose? Follow three simple steps: select several products that fit your budget, test them using trial versions, opt for the most suitable option. If you have in mind any other JavaScript TreeGrid tools, feel free to share your suggestions in the comment section.

Source link

r/graphic_design - Can I get some insight on how I might go about recreating a design a friend of mine had made a while ago?

Can I get some insight on how I might go about recreating a …

A good friend of mine knew this girl that would make her some designs here and there but unfortunately she stopped doing it, and doesn’t have any of her old work. My friend wants one of the designs so she can put it on some shirts but she doesn’t know how to make it herself and I don’t either.
I hope this is the right place to ask or post. Please guide me to somewhere I can ask for advice like this if not.

r/graphic_design - Can I get some insight on how I might go about recreating a design a friend of mine had made a while ago?

This is the only image of the design. The color isn’t part of it just the tree, font and horse. Font says Walnut Tree and Farm with a Walnut Tree and a 5 Gaited horse.

Source link

Top 10 Web Developer Communities Developers Should Join in 2...

Top 10 Web Developer Communities Developers Should Join in 2…

Don’t want to stop learning, improve your knowledge every day as a web developer. Here are the top 10 web developer communities that every developer should join.

  1. StackOverflow
  2. GitHub
  3. Hackernoon
  4. Hashnode
  5. HackerNews
  6. FreeCodeCamp
  7. Dev
  8. CodeProject
  9. IndieHackers
  10. Medium

Web development technologies update every day, hence the software development field is becoming considerably challenging. Therefore you need some sources that can help as the ultimate support system. Where you can share knowledge, ask questions, discuss new things, review codes, learn, etc.

Communities are the collaborative platform for the tech-savvy, expert, competent, and beginner. Where knowledge, individual experience, failures, and skills to be shared to help all other members.

“Learn from the mistakes of others. You can’t live long enough to make them all yourself.” ― Eleanor Roosevelt

I have curated a list of the top 10 web development communities that every individual developer or web development company should join.

Stack Overflow,  a public platform for those who want to learn code, share knowledge, and build their career. It’s a forum posting site where you can ask questions and give answers to tons of web development and computer programming topics.

You can ask many questions every day. Most of the time you’ll get the answer from already asked questions. You can share bugs, errors, issues, or blocks of code and answer a question using your knowledge of programming.

  • Monthly visitors – 100+ Million
  • Question asked to-date – 21+ Million
  • Times a developer got help – 50.6+ Billion

GitHub is a collaborative communication forum site where 65+ million developers working together, share thoughts, ask questions, and help to build projects. You can follow the discussion you are interested in and can share your project with other members to discuss.

GitHub is one of the most patronized and authoritative forum communities globally.

  • Organizations using GitHub – 3+ million
  • Repositories – 200+ million
  • 72% are Fortune 50

Hackernoon is the website for technologists where you can read, write, and publish technical articles internationally. It’s a community of 15000+ tech writers and over 3,000,000 enthusiasts, readers.

Companies such as Adobe, Apple, Alphabet, Google, IBM, Intel, Tesla, Samsung share articles and expertise here. You can write articles on topics such as technology, software, and decentralization with hundreds of different subtopics and publish them.

Hashnode is a global community of programmers. You can share your ongoing projects, stories, ask questions, suggestions, and also give answers to other’s questions. It’s a free platform that helps you to stay connected with the global developers’ community.

You can publish technical blogs or real-life development problems anonymously here. These blogs are shared with all members of the communities, so you can get exposure. Users can follow authors, and tags such as Java, Python, React, JavaScript, CSS, etc.

HackerNews is a social news website for programmers around the world. Developers can share the link of the content, comment, ask questions related to the programming. Best website to learn and grow as a developer. Hundreds of computer science articles are shared every day here.

You can easily share the article by creating an account and submitting it. Readers can upvote and comment on your articles.

FreeCodeCamp is a 100% free nonprofit platform to learn and practice coding. You can learn coding by working on small projects and will get a free certificate from FreeCodeCamp. 40,000+ graduates have gotten jobs in companies including Apple, Amazon, Microsoft, Spotify, etc.

You can use the forum website of FreeCodeCamp where millions of programmers from different countries share thoughts, ideas, problems, and errors to enhance their knowledge.

Thousands of videos on youtube, articles, interactive coding lessons, study groups, and forums help people to learn easily.

An open-source community of 632,417 software developers where coders share, learn, stay up-to-date, help each other, and grow their careers. You can use resources like Podcasts, Articles, FAQs, Videos, News, Real-world examples, and knowledge of others to enhance your coding skills.

This platform covers almost every topic of computer programming such as Angular, React, JavaScript, Python, and CSS. It’s an exceptional website for beginners to learn to code as well as career advice.

CodeProject is a constantly growing community of amazing web developers and programmers with 14,912,384 active members. You can learn by searching articles on topics like Web Development, Artificial Intelligence,  DevOps, Java, .Net, C++, Database, etc. You can even share your knowledge as well.

You can ask questions, write answers, and discuss more than 20 computer programming topics (C#, Web Development, AI, C, C++, Java, JavaScript, DevOps, ASP.Net, IoT, Linux programming, iOS, DataBase) with millions of skilled web developers around the world.

IndieHackers is an emerging online community of world-class web developers. It’s a place where founders of successful startups share their stories, revenue, and experience with other members.

You can learn from the success stories of aspiring entrepreneurs and get connected with the thousands of other founders who are growing their companies.

The website provides a forum where every member can share experience, knowledge, explore ideas, and offer support. To date, 20,000 members have registered to IndieHackers.

Medium is the best medium to improve your knowledge of computer programming, and web development. Almost every tech-savvy used to publish a highly professional piece of content here. You can learn from those thousands of tech articles. You can comment, upvote, subscribe, and connect to the author directly.


We know the internet has connected the whole world, now no one is too far to share knowledge. These communities are supporting the progress of web development and computer programming. You can explore your knowledge of programming with such helpful communities available on the internet.

These aren’t just groups, we can say these are the family of people who appreciate other work, helps to grow, and make the web a better place to learn.

Source link

The design for, with header, footer, and various body sections.

A Step-By-Step Process for Turning Designs Into Code

Turning website design files into a combination of HTML, CSS and JavaScript is the bread and butter of many front-end web development jobs, but there’s a part of this work that doesn’t neatly fit in to tutorials on any specific topic. There’s a process of breaking down a design and figuring out how to approach the build that seems to fall under on-the-job training for new front-end developers. It’s not something taught alongside core technologies (no matter where we are learning those technologies—college, bootcamp, or on our own).

In this post, we’ll take a look at how to go from design to code, and why you might want to follow a process like this instead of just diving into code head-first—which, let’s face it, we love to do! The contents of this post are based on my experiences onboarding new developers, the kinds of conversations we’ve had, and the help and feedback I’ve provided in those situations.

One reason the process of moving from design to code is a core professional skill for a front-end developer is that without having some way to dig in and predict how you will approach something, it’s very difficult to provide an estimate for how long it takes to make or what questions you might need answered before you start. Many designs might appear simple at first glance, but quickly become complex once you get into the weeds. I’ve seen this lead to overpromises, which often leads to tighter deadlines, stress and even worse side effects. Suddenly everything takes much longer than we initially thought. Yuck. Let’s see if we can avoid that.

Evaluating a design

As a way to talk about this, let’s use an example design for a “marketing-style” web page and assume we have been asked to implement it. We can also assume this site is created in a context where marketing professionals may come in and edit the content via some content management system (CMS), re-order the sections, replace images, and make style changes. So we need to decide on the components of the page that will be the building blocks used in the CMS.

This gets at another reason that this can be missed in education: often in our own solo projects, we can have static content right there in the HTML, and component parts aren’t going to be Frankenstein-ed together by strangers to form whole new pages and sections. But once you step into more real-world dev situations, things are a lot more dynamic, and we are often working at the layer of “make things that a non-developer can use to make a web page.”

The design for, with header, footer, and various body sections.
Design made by and courtesy of my friend, Dan Ott

Let’s use this website for a clinical trial is example. As we can see there are a lot of familiar design elements. Marketing sites tend to share common patterns:

  • a big hero section
  • product images
  • small separate sections of short-form content emphasizing one thing or another
  • information about the company
  • etc.

On mobile, we can take it as a given that in each section, the left columns will stack on top of the right, and some other fairly typical reflow will happen. Nothing structural will change on mobile. So what we are looking at is the core of the design.

In this example, there is a header, then a lot of distinct sections, and a footer. At a glance, some of the sections look kind of similar—several have a two-column layout, for example. There are button and heading styles that seem to be consistent throughout. As soon as you take a look at something like this, your eye will start to notice repeated patterns like that.

This is where we start making notes. Before we do any coding, let’s understand the ideas contained in the design. These ideas can fall into a few buckets, and we want our final product—the web page itself—to correctly represent all these ideas. Here are the buckets I commonly use:

  1. Layout-level patterns—repeating layout ideas and the overall grid
  2. Element-level patterns—headings, text sizes, fonts, spacing, icons, button sizes
  3. Color palette
  4. Structural ideas—the logical organization of sections, independent from the layout
  5. Everything else—ideas that are only present in one component

Documenting the patterns this way comes in handy for figuring out our CSS approach, but also for choosing what HTML elements to use and starting conversations with the designer or other stakeholders if something is unclear. If you have access to the source files for the design, sections and layers might be labelled in there that give you a good idea what the designer was thinking. This can be helpful when you want to talk about specific sections.

So let’s look at the ideas contained in our example design. We’re going to do several passes through the design, and in all of them, we’re going outside-in, top-to-bottom, and left-to-right to ensure we evaluate every element. In each of the five passes, we’re looking for stuff that goes into just one of the buckets.

We’re unconcerned with getting this list perfect; it can always be changed later—we just want to record our first impressions.

Pass 1: Layout-level ideas

In this design we have a few layout ideas that stand out right off the bat.

  • A header with a horizontal nav section
  • A main content column within the content area—left and right edges align within all sections from header to footer
  • Sections with two columns
  • Sections with a single centered column
  • Sections with a single left-aligned column
  • A footer with three columns
  • Fairly generous padding inside each section
First impressions

We should note any other first impressions we have during this first pass, good or bad. We can never have a first impression twice, and some of our gut reactions and questions can be forgotten if we neglect noting them now. Plus, identifying specific stuff that you like in the design can be nice when we get to talking with the designer. It both helps to celebrate the good stuff and mix it in with other constructive criticism.

Our first impressions might be things like:

  • 👍 The design is clean-looking and readable.
  • 👍 The sections are all titled by questions (good, helps draw reader in and gives each section a clear purpose).
  • 🤨 Question marks are used inconsistently in the titles (possibly just an oversight?).
  • 🙋‍♀️ Sometimes there are very similar font sizes right next to each other (may need to follow up to see if this is intentional because it seems a less slick and professional than the rest of the site).
  • 👍 The logo is nice with that little gradient going on.

Pass 2: Element-level ideas

The section of the CVS Hope page explaining Cyclic Vomiting Syndrome. Regions are highlighted containing different font sizes in side-by-side paragraphs.

Here are things we might notice in this second pass:

  • Primary (blue) and Secondary (white) button styles, plus a “Learn more” button in the header with a little arrow (an expanding menu maybe?)
  • Heading and sub-heading styles
  • Three “body text” sizes (16px, 18px, 20px)
  • A “dark-mode” section where text color is white and the background is dark
  • A consistent presentation of “image & caption” sets
  • Custom bullet points of various kinds
  • Inline links in the text are underlined and, other links, like those in the footer, are not.
  • A repeated card component with an icon on top, and a heading and a list inside the card
  • The logo repeats a few times in different contexts/sizes.
  • The footer contains uppercase headings that don’t appear elsewhere.

Pass 3: Color palette

There is not too much going on in this design color-wise.

  • blue/purple primary color
  • light/dark body text colors
  • light/dark link colors
  • nice gradient under the word “hope” in the logo
  • light gray background color
  • dark navy background color
  • specific red and green “checkmark” and “stop” icon colors

Some design tools let you export the color hex values used in the design file, or even full-on Sass or CSS variable declarations. If you have that option, use it. Otherwise, find your own way to grab those values and name them because those are the foundation for lots of our initial CSS work.

Throughout our CSS and other code, we want to be refer to colors with labels or classes like “primary” and “secondary” that we can reuse throughout the code. This makes it easier to adjust values in the future, and to add themes down the line if we ever need to.

Pass 4: Structural ideas

This is where we might actually name the regions of the page in ways that make sense to us, and identify the hierarchy of the content. We can start to understand the accessibility needs of our implementation by documenting in plain language what we see as the nature and structure of the content in the page. As always, going outside-in, top-to bottom, left-to-right as we make our evaluations.

Focusing on structure helps us figure out the underlying patterns that eventually become our components, and also helps us understand the way we want people who use assistive technology to perceive the content. In turn, that guides us as far as what HTML elements we need to use to write semantic HTML. Semantic HTML speaks to the nature and structure of the content so that it can be perceived correctly by browsers. Browsers use our HTML to create the accessibility tree that assistive tech, like screen readers, uses to present the page. They need a strong outline for that to succeed and semantic HTML provides that solid structure.

This means we need to understand the nature of what’s on the page well enough that we could explain it verbally with no visual support if we had to. From that understanding, we can work backwards to figure out the correct HTML that expresses this understanding via the accessibility tree, which can be inspected in you browser’s developer tools.

Here’s a quick example of the accessibility tree in Chrome if everything on the page is a div, and if elements are correctly chosen to match the nature of the content. Determining the best element choice in a given situation is outside the scope of this post, but suffice it to say that the expressive, non-”generic generic generic” accessibility tree below is entirely created with HTML elements and attributes, and makes the content and its organization much easier for somebody to perceive using assistive technology.

Three screenshots of an accessibility tree. One is made up only of generic containers, the text beside it reads. “Div soup - ignores the nature of the content.” The next is all generic but has a main parent element and one article element with a title, “What is Cyclic Vomiting Syndrome (CVS)?” The text beside it says the article is the odd one out and that we will look closer. The final image is the article element expanded in the accessibility tree, showing that it contains headings, paragraphs, and other semantically appropriate HTML elements. The text beside that one reads “Semantic markup! Stuff knows what it is!”

So, in this fourth pass, here are notes we might make:

Not so bad for the first top-to-bottom pass. Let’s go a level deeper. We’re still unconcerned with the child inside elements of the sections themselves yet—we want just enough info to label the top level items inside each sections.

  • Within Header there is:
    • Home link
    • Navigation section
  • Within Main Content there is:
    • Hero section
    • Short explainer about the disease itself
    • Explainer about the treatment
    • Intro to the trial
    • Explainer with more details about the trial
    • Statement about who can join the study
    • Call-to-action to participate
    • Short explainer about the company
  • Within Footer there is:
    • Logo
    • Summary Sentence
    • Some lists of links with titles
    • Divider
    • Copyright notice

This pass reveals a few things. First, the Header and Footer sections are pretty shallow and are already revealing raw elements like links and text. Second, the Main section has eight distinct subsections, each with its own topic.

We’re going to do one more pass here and get at some of the deeper details in those sections.

  • Header home link—Woohoo, it’s just a link and we’re done.
  • Header nav—This is an expanding hover nav that needs JavaScript to work correctly. There are probably lots of accessible examples to follow, but still will take more time to develop and test than if we were working with raw links.
  • Hero
    • Title
    • Column 1
      • Subtitle (we missed this in the first element-level pass)
      • Paragraph
      • Primary button link
      • Secondary button link
    • Column 2
  • Disease Explainer
    • Title
    • Paragraph
    • Unordered list
    • Large text
    • Unordered list
    • Image and caption (figure and figcaption)
    • List of links
  • Treatment Explainer
    • Title
    • Column 1
    • Column 2
      • Image and caption (figure and figcaption)
  • Trial—Intro
  • Trial—More Details
    • Title
    • Subtitle
    • Cards (with Icon, Title, and List)
  • Who Can Join” statement
  • Call-to-Action
    • Title
    • Paragraph
    • Secondary button link
  • About the Company

Yowza, that got long fast! But now we understand pretty well the kinds of things we need to build, and what parts might be tricky. We also see that there may be some helper components to be built that aren’t quite represented by any one of these sections, for example, a two-column layout component that stacks to one column on mobile and has a title on top, or a generic “section container” component that takes a background and foreground color and provides the right styles plus standardized internal padding.

Incidentally, with this breakdown we’ve done a pretty good job expressing the final accessibility tree we want our HTML to create, so we are well on our way to having the implementation be a smooth experience without a lot of re-work to get accessibility right.

Pass 5: Everything else

What are some other ideas contained in this design, things that stick out, or challenges we notice? Maybe not much, but this is kind of the other side of the “first impressions” notes. Now our heads are filled with context for what it is in the design.

If something stands out now, especially if it’s a question about how something works, capture it. An example is, “Hmm, what is the ‘Learn More’ link in the nav supposed to do?” The answer might be: “It’s a list of links to each section that open when you hover there.” Every now and then, a designer expects that this kind of thing is already implied in the design, even if it is not explicitly documented, and it only comes up at the design review stage after that thing is developed—which is often too late to correct without affecting dates and deadlines.

We should also now look deeply and identify any hidden “glue work”— things like getting our styles in order, handling mobile, configuring the CMS, adding and testing authoring options and arrangements for our building blocks, and adding automated tests. Stuff like that.

At this point, we are ready to nail down exactly what components can be created in the CMS. Maybe we already have some of the basic setup done in the current system from past work. Whatever the case, we have enough to draw on to offer a decent estimate of the work needed, grouped into categories. For example, we might categorize components that:

  • are already 100% ready (no dev time needed),
  • exist but need tweaks for this new purpose (predictable dev time needed),
  • are totally new, but the path is obvious and safe (predictable dev time needed),
  • are totally new and need some research to implement. Or the design is unclear, or something about it gives you the heebie-jeebies and you need to have discussions with stakeholders. The earlier you can spot this, the better. Talk it over with whoever is running the project.

Now we have enough information to make a reasonable estimate. And more to the point, we’ve reduced the total time the project will take, and limited the trouble we might have along the way, because we’ve gained several advantages from planning it out.

The advantages of having a process

The exact steps we take and what order they are completed in is not the main point. What matters most is understanding the kind of information you need to gather when starting on a project. You might have your own ideas about how the work is done and in what order, whatever works for you is great.

Here are the advantages I’ve realized when assessing a design with a process in mind, compared to just kinda diving in, “getting stuff working,” and handling things as they come up.

As much as we’d like every project to arrive fully formed and perfectly ready to start, in reality, designs often contain assumptions that might be impractical to implement, or contradict something else we care about, like accessibility. In that case, you can assess the whole thing up front and get the conversations started with people who can resolve those issues early in the process. This can happen while you dive into the pieces that are ready to code, and will stop you from bumping into these roadblocks later when you are about to build that part of it. Flagging concerns early is definitely appreciated by the people who need to solve them.

You can be helped by others

Without a plan, it can be difficult to understand how far along you are in completing the project, as well as knowing if you need help meeting a deadline. Even if you do need help and are able to ask for it, it’s tough to use extra helping hands effectively without the work being broken out in to separate little chunks that be easily divided. When you have a plan that makes sense, you can quickly delegate certain tickets, knowing that the jigsaw pieces will fit together in the end.

It’s easy (and common) for a new developer to think think that huge workloads and working around the clock is a good thing. But as you mature in the role, you’ll see that having a deep understanding of the whole picture of a project, or even a single ticket, is more valuable, while creating a better impression that you are “on top of things.” Recognizing early that a timeline doesn’t look right gives you options about how to address it in ways other than trying to be a hero and throwing some weekends at it.

Component architecture flows better

Architectural decisions are the worst for me. Naming components, figuring out where stuff should live, which components need to talk to each other, where to break stuff up into smaller components. A lot of those choices only make sense when we look at the bigger picture and think about all various ways that certain elements might be used by visitors and content creators. And a lot of these choices are marginal—choosing the “best” option between two acceptable solutions can be a huge time suck or completely subjective.

Have a process helps with that because you are going to get all, or most, of the information you need about the designs before digging deeply into the development work. For me, figuring out what pieces I need to make, and figuring out the best possible code to make those pieces, are two different things. Sometimes what I need is not the thing that comes most naturally from the code. And sometimes, after learning a bit about what is needed, I can avoid time spent bikeshedding marginal decisions because it’s more clear which decisions truly don’t matter.

You still learn new things as you write the code, of course, but you’re now better prepared to handle those things when they pop up. You even have a good idea about the kinds of that might present themselves.

Styles make more sense

As you plan the work, you can truly figure out which styles are global, which are section-specific, which are or component-specific, and which are one-off exceptions. If you don’t already have a system you like for this, Andy Bell’s Cube CSS pairs very well with the kind of breakdown I’m talking about. Here’s a video of Andy working through an example with Chris Coyier that you can check out for more about this approach.

Accessibility starts early in the process

This one is huge for me. By really understanding the ideas contained in the design, you will have an easier time picking semantic HTML elements and finding appropriate accessible patterns to build out what you see there. Accessibility can work its way into the daily work you do, rather than an afterthought or extra burden. Our perspective becomes that high-quality front-end code correctly expresses the nature and structure of its content to all users, and accessibility is how we measure that.

After a pretty short period, you’ll see how often designs conform to one known pattern or another, and the flow of breaking something down into known patterns to implement will speed up dramatically. Carie Fisher nicely sums up ideas related to this “Accessibility-first” approach.

Wrapping up

Like I said at the start, a lot of this falls under on-the-job training, the “oral tradition” of web development. It’s the kind of stuff you might hear from a senior developer on your team as you’re getting started in your first front-end role. I’m sure lots of people would have different priorities than I do and recommend a slightly different process. I also know for sure that a lot of folks out there work in situations without a solid process in place, and no one senior to consult.

If you are in that situation, or not yet in your first role, I hope this gives you a baseline you can relate to when you think about how to do the job. Ideally the job is not just diving in and putting stuff in divs until things look “right” but that is often our mode of operation. We are eager to make progress and see results.

I’m very grateful that I did have somebody working with me at my first development job who showed me how to split up pieces of a design and estimate work for large, long-term projects. That’s what inspired me to start thinking about this and—as I began supervising other developers and teams—thinking about how I wanted to adapt the process and make it my own. I also realized it wasn’t something I’d noticed people talking much about when teaching technical skills about using a particular language. So thanks, Nate!

Thanks also to Drew Clements and Nerando Johnson for providing early feedback on this post. You are the best.

Source link

Setting Up Authentication

Securing Modern Development Lifecycle in The Cloud

Web developers in the modern era often create different kinds of Web APIs and publish them to some platforms. In recent years probably even some Cloud platforms. These APIs are then consumed by some SPA applications (React, Angular, or similar SPA applications), mobile, or desktop applications. However, security best practices must be applied and this is something a lot of developers struggle with. In the Azure platform, we have some powerful features in place to ensure we can develop securely end-to-end. One example is the Microsoft Identity Web provider. The main advantage of using this provider is that we don’t need to know protocols such as OpenID Connect or OAuth and this enables us to not be involved manually in all changes of these protocols that happen all the time.

Microsoft Identity Platform

Microsoft Identity Web is a library that contains a set of reusable classes used in conjunction with ASP.NET Core for integrating with the Microsoft identity platform (formerly Azure AD v2.0 endpoint) and AAD B2C. It can be also used with desktop and mobile applications.

The Microsoft Identity platform supports authentication for different kinds of modern application architectures. All of the architectures are based on the industry-standard protocols OAuth and OpenID Connect. By using the authentication libraries for the Microsoft identity platform, applications authenticate identities and acquire tokens to access protected APIs.

Protecting Web APIs in this case is done by calling an API through an access token. The token helps secure the APIs data and authenticate incoming requests. The caller of a web API appends an access token in the authorization header of an HTTP request.


To start with using the Microsoft Identity platform to protect Web APIs, you need to have:

  • An Azure account with an active subscription. Create an account for free.
  • An Azure AD tenant.
  • An ASP.NET Core Web API application. In this example, we will use the default Web API application crated from Microsoft Visual Studio 2019.

Creating a Simple Web API

If we create a new app, it is important to select the proper Authentication type — Work or School Accounts, that will be authenticated with Microsoft Azure Active Directory (AD).

Setting Up Authentication

In appsettings.json there will be a defined AzureAd field with all important properties to connect to the Azure AD, such as InstanceDomainTenant ID, and Client ID.

appsettings.json Properties

This section from appsettings.json will then be used in Startup.cs to define Microsoft Identity Web Api as an authentication type.

Section Used in Startup.cs

Register the API Application With Azure AAD

When we have created and configured the application the next step is to register the application within the (Azure) portal. Here we need to register one application (the API) we are protecting and another one will be created for each client we want to consume this API from. An example of such a client could be Web application (SPA), mobile application, etc. In the following example, we will use Postman.

Register the API Application

To authenticate against Azure AD we need to add Azure AD application registrations and this can be done through the Azure portal: > Azure Active Directory > App registrations > New registration.

Registering an API Application
  • Enter a name, here one can choose the name of the application and ‘Api’. Example: Protected API app.
  • Choose who can access your application. Here I am choosing the option that allows anyone that has an Azure AD Account or consumer account access to the API. That is Accounts in any organizational directory (Any Azure AD directory — Multitenant) and personal Microsoft accounts (e.g., Skype, Xbox).
  • Click “Register.”

When the app registration is complete we can see the Client ID and Tenant ID in the Azure overview and copy those ID’d we will need in configuration setup.

Completed Registration IDs

Creating Scopes

The Scope is a mechanism in OAuth 2.0 to limit an application’s access to a user’s account. An application can request one or more scopes, this information is then presented to the user in the consent screen, and the access token issued to the application will be limited to the scopes granted.

Here we are going to create one scope and use it in our application.

In the Azure portal, go to the API application registration and click on “Expose an API.” Here we will see something like “Application ID URI,” click “Set.” You’ll something like api://e6ae15e8-3321-4035-83c1-6b38664404a5. This is used as the base of your scopes, the GUID is automatically generated.

Here we will add one scope for every permission we want. We want only read permission so we will create just one scope.

Update the Web API Project to Use Azure AD Authentication

We need to configure the Azure Active Directory setup in appsettings.json by adding the application (Client ID) and Tenant Id.

The Authentication type Microsoft.identity.platform helps in the integration of Azure AD and it will add all the basic configuration setup in the respective files.

Configuring Azure Active Directory (AD)

We will adjust our code to accept only accept tokens 1) for users, and 2) having the “ReadAccess” scope for this API.

Adjusting Code to Only Accept Specific Tokens

After this point, we can create and publish the application on the Azure App service, e.g., by using Web deploy (right-click on the solution and click Publish). If there is not created App service from this menu you can create it.

Creating and Publishing Application to Azure App Service

Testing the API With Postman

Now when we have deployed our API in Azure, we want to use Postman to test it. The first thing we need to do is to configure Callback URLs. Go to Azure portal to the App registration and click on the Authentication menu, under the Platform Configurations, add the platform (Web) and the Redirect URLs — add the Postman call back URL’s — for Postman desktop or for Postman Web app and application callback URL.

Platform Configurations

When we created redirect URIs we need to create a client secret too. This is done in the “Certificates & Secrets” menu and then “New client secret.” Set the description and duration as never. Add click on create it will create a token. Copy it as you won’t see it again.

Certificates and Secrets

In the final step, we can go to the Postman, create a new GET request to our deployed API (

In the Authorization tab, we need to choose OAuth 2 from the Type list and choose Request Headers in Add authorization data to the Values for Authorization in Postman.

Token Configuration Options

Once you fill up all the fields you can skip the State field, click on the Get New Access Token button. It will popup the Azure AD login dialog and you can log in. Once the login is completed, Postman will show a Token, which can be used to talk to the API.

Selecting Microsoft Account

Below is the token generated by authenticating with our credentials click on > Use Token > it will automatically add in the request header.

Manage Access Tokens

After the successful Authentication, now we can send the GET request which will return the JSON result, like this.

Returning JSON Result


401 Forbidden

If you get a error_description with it like Bearer error="invalid_token", error_description="The audience '*some guid*' is invalid". This means you have the wrong client id in your appsettings.json. If you don’t get an error_description with it, that generally means something is wrong with the application registration. Go over the steps above.

500 Internal Error

You should get an error message with this. The most likely cause is that the name of the scope you have in the C# code does not exist in the token.

Adjusting Existing ASP.NET Web API

In this example, we started already with the solution that uses Microsoft Identity Web for authentication, which we adjusted. If you have an existing ASP.NET Core Web API which you need to adjust, you need to make the following steps (if you don’t need to do it, just skip this section):

Install NuGET package Microsoft.Identity.Web:

Install-Package Microsoft.Identity.Web -Version 1.14.0

In your appsettings.json you will need to add the AzureAd section:

Adding AzureAd Section to appsettings.json

In the Startup.cs, we need to enable the Microsoft Identity Platform. In the ConfigureServices method, add as one of the first lines in the method.

Enabling Microsoft Identity Platform

In the Configure() method we need to have:

Needed For Configure() Method

Also, we need to decorate our controller with [Authorize] attribute.

Finally, we need to add the following code to any methods that we want to check permissions for. In the case you do not provide other scopes or don’t add this scope to any other methods, they will no longer be accessible.

Code For Methods we Want to Check Permissions For

Storing Secrets in .NET Applications

When we have protected our API, to have our application bulletproof in terms of security for modern software development lifecycle, we need to manage secrets and credentials used to secure communication between different components. Storing secrets in places like a configuration file can expose our application to vulnerabilities similar to the ones due to bad programming practices or bugs. This could be a big challenge for a developer. Whether it’s a database password or a connection string for some service. However, Microsoft Azure offers us a specific kind of service for this type, called Azure Key Vault. It is a Cloud service for securely storing and accessing secrets.

Here we will discuss how to set up Azure Key Vault, store some secret inside and read it from .NET app by using Azure Managed identity. Managed identity is a solution in the Cloud that eliminates the need for developers to manage credentials. Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications may use the managed identity to obtain Azure AD tokens.

There are two types of managed identities:

  • System-assigned, which is enabled for us directly on the Azure Cloud instance.
  • User-assigned identity, which is a standalone Azure resource that can be created independently from concrete service instances.

Enable the Azure Managed Identity

The first step we need to do is to enable system-assigned Azure managed identity for our application or API. From the App service settings menu (left side) we choose Identity and switch the Status toggle to be On. Here we should see the Object ID value displayed.

Enabling the Azure Managed Identity

Create the Azure Key Vault Instance

Now we need to create an instance of Azure Key Vault. We do this in the Azure portal by following these steps. When we have created Key Vault we will add a secret inside. From the left menu of the Key Vault configuration page, we select Secrets from the Settings section. Then, we click the Generate/Import button. For the Upload options, we select Manual. For the Name, we can choose Some-app-secret. For the Value, we can enter e.g, “Our secret code” and click Create button.

Creating Azure Key Vault Instance

Granting Access to The Secret

To access this secret from our application we need to grant access to it. From the left menu of the Key Vault page, we select Access policies, and then we click + Add Access Policy. From the Secrets permissions, we can choose List and Get, which will allow us to list and read secret values stored in the Azure Key Vault. Then, we click the Select principal link. In the search box, we have to provide the value of Object ID for the system-assigned managed identity we created above for our Azure Web API instance. We have to select it from the list and click the Select button. Finally, we click Add and Save buttons.

Granting Access to the Secret

Storing Secrets Locally

If we want to store secrets locally, we can use the Secret Manager. The Secret Manager tool stores sensitive data during the local development of an ASP.NET Core project, but it hides implementation details, such as where and how the values are stored. How we can use the Secret Manager, you can read here.

We can enable it by adding:

dotnet user-secrets init

or from Visual Studio, right-click the project in Solution Explorer, and select Manage User Secrets from the context menu.

Manage User Secrets From Context Menu

Here we can add or remove secrets in the form of key-values pairs to be stored.

Prepare the Application to Read Secrets

To read secrets from Azure Key Vault in our Web API, we need to add some NuGet packages. With these packages, we can use managed identities to access Key Vault secrets from ASP.NET Core Web API application.

  • Microsoft.Extensions.Azure — we use this package to inject dependencies for using different Azure SDK clients for accessing Azure services.
  • Azure.Security.KeyVault.Secrets — this package is used used to select SecretClient instances to access secrets stored in the Azure Key Vault.

To authenticate with managed identities, we will use the class DefaultAzureCredential.

Accessing Secrets Stored Locally and In the Cloud

Now, if we want to read our secret from local storage we can do the following, e.g., in Startup.cs:

Reading Secret From Local Storage

On the other side, if we want to read the same secret value from our Key Vault store in Azure we setup, we can use the SecretClient class instance, e.g.:

Using SecretClient Class Instance

Uri for your Key Vault you can copy from the Overview screen of previously created Azure Key Vault in the step Create the Azure Key Vault instance.

Wrap Up

In this article, we have seen how to use different aspects of the Microsoft Identity Platform to protect our Web APIs, but also how to use it to eliminate the requirement to store secrets in application configuration files. By using it, we can directly access different resources without using connection strings and passwords and significantly improve the security aspects of our application.

Source link

Vince Speelman

The Nine States of Design. A Lifecycle for Components that s…

Vince Speelman

Modern UI teams are designing components first; Interfaces are merely the thoughtful composition of components. This leaves an often glaring hole for users on “the unhappy path” — The places where users may, intentionally or not, stray from your idealized flow. As we learn to craft systems rather than pages, we must invest effort into shaping these often missed states of design and create with a component lifecycle that can support everyone. Here’s the lifecycle as I see it:


  1. Nothing

What happens before your component does anything? Maybe it’s the first time a user sees it. Maybe it’s not activated yet. Essentially, the component exists but hasn’t started.

Jonas Treub makes sure framer gets you up to speed.

2. Loading

The dreaded state. In a perfect world, no one would ever see this; Alas, here we find ourselves. There are plenty of ways to keep your loading state subtle and unobtrusive. Facebook does a pretty good job of this:

Facebook uses a “dummy post” rather than a traditional loading spinner.

3. None

Your component has initialized, but it’s empty. No data. No Items. Now may be a good time to get the user to act (“Do this thing!”), or to reward them (“Good job, everything is taken care of”).

Luke Seeley knocked this one out of the park.

4. One

You have some data. On an input, this may be after the first keystroke. In a list, it might be when you have one item (or one left).

Luke Seeley again for MetaLab.

5. Some

This is usually what you think of first. What is the ideal state for this component? Your data is loaded, you have input, and the user is familiar with it.

A big comfy dashboard from UENO.

6. Too many

Woah there! The user has overdone it in some way. Too many results (maybe you paginate them now), too many characters (maybe ellipses?), and so on.

Good ol’ pagination from Pete Orme

7. Incorrect

Something is not right about the component. An error has occurred.

A nice error state from

8. Correct

Good to go! This item has had its needs satisfied.

short form Ionut Bondoc ( ►IB )

9. Done

The user’s correct input has been received by the application. They don’t have to worry about it anymore.

Igor Chebotarev gives some positive feedback.

Source link