top

Polymer And PWA: Understanding The “Why” — Part 1

In this article series, we will understand-A brief history of the evolution of webThe drawbacks of the current state of web platform?How web components proposes to solve those issues?How Polymer fairs as a web component library and a lightweight frontend framework?The out of the box support for PWA and other performance best practices polymer providesYou can easily get started with progressive web app polymers by understanding all the above concepts clearly.The creation of HTML & JSHTML was created to share documents over the network. It supports three features mainly, i.e. display text, images, and interlink with other HTML documents. Everything was pre-created and servers distributed only static HTML pages. Below is the image of a typical browser from the 1990s.Then they wanted to programmatically control HTML and add behaviors to HTML and browser. Hence Javascript was created.Evolution of browsersWeb servers started to serve dynamic content unlike the static contents before. This lead to HTML spec evolution. Browsers started sending data to servers via forms and then AJAX. Browsers got more powerful as Javascript spec progressed. We got to a stage called WEB 2.0 where we started doing complex business logic processing at frontend. Patterns for development emerged and grew into libraries and frameworks. This has emerged polymer as an important library for building a progressive web app from scratch.Framework WarsThere were a lot of competing frameworks to enable the complex frontend apps. Each had their own set of philosophies and build tools. This was essentially the web performance race with every new framework/version improving upon its predecessors. But, creating progressive web apps with polymer supports modern enhanced web platform.Where is the web platform today?We are cluttered and fragmented with frameworks. Each one has a twisted philosophy of performance and has laborious (automated yes, but try tweaking them) build process. All of this is a workaround on how the platform is today.What did we lose?Interoperability: We can’t use components built in different frameworks together with ease. Imagine if you are a big organization and your departments would have a lot of similar looking UI with slight modifications. Now, each department would choose their own framework to build the UI. As an organization, we can’t leverage the work of other teams.Simplicity: We are all aware of the term javascript fatigue. There is so much churn in the frontend world each day that we have to make ourselves familiar with so many things. Each framework enforces its own abstractions of concepts and architecture that your skills are not transferable. You need to be a seasoned engineer to switch between frameworks and write near-perfect code. Others would have a steep learning curve and might take time picking up best practices.Things we didn’t anticipateWhen the frameworks came out they were mainly run on desktops and laptops. No one thought about the mobile web. Most frameworks are too heavy to run on mobile. The parse, compile, execute and render would put a huge load on the mobile CPU. But the computational power on mobile is limited. They don’t have big heatsinks like desktops. Without a heatsink, there would be an upper limit on the processing power of a mobile CPU.Mutation of HTML                                                                       This is a screenshot of Youtube webpage HTML codeIn the Image above we can see how a typical HTML looks like for any website today. I call that built with <div> soup.                                                                                                          Div SoupIt is common to see code like <div class=”tree-control”> where the behavior of tree control is forced on to a scaffolding HTML element div.                                                                                                   Forced BehaviorHTML moved away from original purpose and capabilities. HTML was not meant for Web Apps. All it was supposed to do was have the ability to display documents over the network and link to other documents (https://www.w3.org/History/1989/proposal.html). So the frameworks that exist today are a workaround on the way the platform evolved and trying to do things which were not supported by the original vision.Time to redesign the HTML/Web                                                                 This is a screenshot of YouTube written with web componentsWhat if we create a element <tree-control> instead of writing <div class=”tree-control”>. That would be an easy and natural to understand. It puts the information where it belongs and preserves the semantics.But <tree-control> is not a default HTML element. How would browser parse it? Well, web components are the answer to that question.Web ComponentsWeb components are based on four main specifications that introduces you to progressive web app polymers.Custom ElementsThe Custom Elements specification lays the foundation for designing and using new types of DOM elements.Shadow DOMThe shadow DOM specification defines how to use encapsulated style and markup in web components.HTML importsThe HTML imports specification defines the inclusion and reuse of HTML documents in other HTML documents.HTML TemplateThe HTML template element specification defines how to declare fragments of markup that go unused at page load, but can be instantiated later on at runtime.( Intro on web components borrowed from https://www.webcomponents.org/introduction )In simple terms, web component allows you to define your own HTML tags, enables you to define blocks of markup with the ability to inject dynamic content, gives you the ability to scope/encapsulate markup and styles in a separate DOM tree and provides a way to include and reuse HTML documents in other HTML documents.                                                        You might say, hey!! popular frameworks already do something like that!You might say, hey!! popular frameworks already do something like that! So let me take a look at the diagram below to understand the differenceYour typical frameworks operate at the Javascript level, which means when you insert your template into the page it parses the HTML, identifies if a definition for <tree-control> is present. if so it takes control of it and handles its lifecycle and its DOM activities. All of this is not native. So there is only so much performance optimization it can give us.Whereas when you use web components we tell the browser what to do when it encounters a <tree-control> tag. We describe its life cycle to the browser. The browser is informed of the DOM manipulations. So what happens here is that browser is in control. It runs on a native layer which means that it will be faster than what frameworks do. This gives your web pages a default win.Hope this Progressive web app polymers tutorial helped you to understand the basics of Polymer and PWA.In the next part of the article, we shall explore Polymer, a javascript library that helps you create custom reusable HTML web components and all benefits that come with it.
Rated 4.0/5 based on 31 customer reviews
  1. Home
  2. Magazine
  3. Polymer And PWA: Understanding The “Why” — Part 1
Normal Mode Dark Mode

Polymer And PWA: Understanding The “Why” — Part 1

Ashrith Kulai
Blog
20th Apr, 2018
Polymer And PWA: Understanding The “Why” — Part 1

In this article series, we will understand-

  • A brief history of the evolution of web
  • The drawbacks of the current state of web platform?
  • How web components proposes to solve those issues?
  • How Polymer fairs as a web component library and a lightweight frontend framework?
  • The out of the box support for PWA and other performance best practices polymer provides

You can easily get started with progressive web app polymers by understanding all the above concepts clearly.


The creation of HTML & JS

HTML was created to share documents over the network. It supports three features mainly, i.e. display text, images, and interlink with other HTML documents. Everything was pre-created and servers distributed only static HTML pages. Below is the image of a typical browser from the 1990s.


Then they wanted to programmatically control HTML and add behaviors to HTML and browser. Hence Javascript was created.

Evolution of browsers

Web servers started to serve dynamic content unlike the static contents before. This lead to HTML spec evolution. Browsers started sending data to servers via forms and then AJAX. 

Browsers got more powerful as Javascript spec progressed. We got to a stage called WEB 2.0 where we started doing complex business logic processing at frontend. Patterns for development emerged and grew into libraries and frameworks. This has emerged polymer as an important library for building a progressive web app from scratch.


Framework Wars

There were a lot of competing frameworks to enable the complex frontend apps. Each had their own set of philosophies and build tools. This was essentially the web performance race with every new framework/version improving upon its predecessors. But, creating progressive web apps with polymer supports modern enhanced web platform.


Where is the web platform today?

We are cluttered and fragmented with frameworks. Each one has a twisted philosophy of performance and has laborious (automated yes, but try tweaking them) build process. All of this is a workaround on how the platform is today.

What did we lose?

Interoperability: We can’t use components built in different frameworks together with ease. Imagine if you are a big organization and your departments would have a lot of similar looking UI with slight modifications. Now, each department would choose their own framework to build the UI. As an organization, we can’t leverage the work of other teams.

Simplicity: We are all aware of the term javascript fatigue. There is so much churn in the frontend world each day that we have to make ourselves familiar with so many things. Each framework enforces its own abstractions of concepts and architecture that your skills are not transferable. You need to be a seasoned engineer to switch between frameworks and write near-perfect code. Others would have a steep learning curve and might take time picking up best practices.


Things we didn’t anticipate

When the frameworks came out they were mainly run on desktops and laptops. No one thought about the mobile web. Most frameworks are too heavy to run on mobile. The parse, compile, execute and render would put a huge load on the mobile CPU. But the computational power on mobile is limited. They don’t have big heatsinks like desktops. Without a heatsink, there would be an upper limit on the processing power of a mobile CPU.


Mutation of HTML

                                                                       This is a screenshot of Youtube webpage HTML code

In the Image above we can see how a typical HTML looks like for any website today. I call that built with <div> soup.

                                                                                                          Div Soup

It is common to see code like <div class=”tree-control”> where the behavior of tree control is forced on to a scaffolding HTML element div.

                                                                                                   Forced Behavior

HTML moved away from original purpose and capabilities. HTML was not meant for Web Apps. All it was supposed to do was have the ability to display documents over the network and link to other documents (https://www.w3.org/History/1989/proposal.html). So the frameworks that exist today are a workaround on the way the platform evolved and trying to do things which were not supported by the original vision.

Time to redesign the HTML/Web

                                                                 This is a screenshot of YouTube written with web components

What if we create a element <tree-control> instead of writing <div class=”tree-control”>. That would be an easy and natural to understand. It puts the information where it belongs and preserves the semantics.


But <tree-control> is not a default HTML element. How would browser parse it? Well, web components are the answer to that question.


Web Components

Web components are based on four main specifications that introduces you to progressive web app polymers.

Custom Elements

The Custom Elements specification lays the foundation for designing and using new types of DOM elements.

Shadow DOM

The shadow DOM specification defines how to use encapsulated style and markup in web components.

HTML imports

The HTML imports specification defines the inclusion and reuse of HTML documents in other HTML documents.

HTML Template

The HTML template element specification defines how to declare fragments of markup that go unused at page load, but can be instantiated later on at runtime.

( Intro on web components borrowed from https://www.webcomponents.org/introduction )

In simple terms, web component allows you to define your own HTML tags, enables you to define blocks of markup with the ability to inject dynamic content, gives you the ability to scope/encapsulate markup and styles in a separate DOM tree and provides a way to include and reuse HTML documents in other HTML documents.

                                                        You might say, hey!! popular frameworks already do something like that!

You might say, hey!! popular frameworks already do something like that! So let me take a look at the diagram below to understand the difference


Your typical frameworks operate at the Javascript level, which means when you insert your template into the page it parses the HTML, identifies if a definition for <tree-control> is present. if so it takes control of it and handles its lifecycle and its DOM activities. All of this is not native. So there is only so much performance optimization it can give us.

Whereas when you use web components we tell the browser what to do when it encounters a <tree-control> tag. We describe its life cycle to the browser. The browser is informed of the DOM manipulations. So what happens here is that browser is in control. It runs on a native layer which means that it will be faster than what frameworks do. This gives your web pages a default win.
Hope this Progressive web app polymers tutorial helped you to understand the basics of Polymer and PWA.

In the next part of the article, we shall explore Polymer, a javascript library that helps you create custom reusable HTML web components and all benefits that come with it.

Ashrith

Ashrith Kulai

Blog Author

Frontend Engineer working on Web Components, Polymer, VueJS and node.js. All views personal.

Leave a Reply

Your email address will not be published. Required fields are marked *

SUBSCRIBE OUR BLOG

TRENDING BLOG POSTS

An Unforgettable Way To Learn Redux- A Visual Guide

The following is a visual guide to learning Redux. One focused on the core Redux principles explained with memorable associations and custom illustrations.Are you Ready?Here we go!Consider an event you’re likely conversant with — going to the bank to withdraw cash. Even if you don’t do this often, you’re likely aware of what the process looks like.                                                                         Young Joe heads to the bank — which happens to be only 3 minutes away.Storytime.You woke up one morning and headed to the bank as quickly as possible. While going to the bank there’s just one intention/action you’ve got in mind i.e to WITHDRAW_MONEYYou want to withdraw some money from the bank.                                                       Young Joe heads to the bank with the intention to withdraw some money.Here’s where things get interesting.When you get into the bank, you go straight to the cashier to make your request known, right?                                                                  Young Joe is at the bank! He goes straight to see the Cashier and makes his request known.Wait, you went to the Cashier?Why didn’t you just go into the bank vault to get your money?                                                                             If only Young Joe got into the Vault. He’ll cart away with as much as he finds.After all, it’s your hard-earned money.Well, you already know that things don’t work that way. Yes, the bank has money in the vault, but you have to talk to the Cashier to help you follow a due process for withdrawing your own money.The Cashier, from their computer, then enters some commands and delivers your cash to you. Easy-peasy.                                                                                                       Here’s how you get money. Not from the Vault, sorry.Now, how does Redux fit into this story?We’ll get into more details soon, but first, the terminologies. 1. The BANK VAULT is to the bank where the REDUX STORE is to Redux                                                                                                                 The bank vault can be likened to the Redux Store!The bank vault keeps the money in the bank, right?Well, within your application, you don’t spend money. Instead, the STATE of your application is like the money you spend. The entire user interface of your application is a function of your state.Just like the bank vault keeps your money safe in the bank, the state of your application is kept safe by something called a STORE. So, the STORE keeps your “money” i.e state, intact.Make sure that you understand and remember this clearly.The Redux Store can be likened to the Bank Vault. It holds the state of your application — and keeps it safe.This leads to the first Redux principle:Have a single source of truth: The state of your whole application is stored in an object tree within a single Redux store.Don’t let the words confuse you.In simple terms, with Redux, it is advisable to store your application state in a single object managed by the Redux STORE. It’s like having ONE VAULT as opposed to littering money everywhere along the bank hall. 2. Go to the bank with some ACTION in mindIf you’re going to get any money from the bank, you have to go in with some intent or action to withdraw money.If you just walk into the bank and roam around, no one’s going to give you money. You may even end up been thrown out by the security.The same may be said for Redux.Write as much code as you want, but if you want to update the state of your Redux application (like you do with setState in React), you need to let Redux know about that with an ACTION.In the same way, you follow a due process to withdraw your own money from the bank. Redux also accounts for a due process to change/update the state of your application.Now, this leads to the Redux principle #2.The State is read-only:The only way to change the state is to emit an action, an object describing what happened.What does that mean in plain language?When you walk to the bank, you go there with a clear action. In this example, you want to withdraw some money.If we chose to represent that process in a simple Redux application, your action to the bank may be represented by an object.One that looks like this:{  type: "WITHDRAW_MONEY",  amount: "$10,000" }In the context of a Redux application, this object is called an action! It always has a type field that describes the action you want to perform. In this case, WITHDRAW_MONEY.Whenever you need to change/update the state of your Redux application, you need to dispatch an action.Don’t stress over how to dispatch an action yet. Just understand what the principle says. Programmatically, here’s how a store is created: import { createStore } from "redux"; //an import from the redux lib import reducer from "./reducers" const store = createStore(reducer); //see the next section for how the imported reducer is created 3. The CASHIER is to the bank where the REDUCER is to REDUXAlright, take a step back.Remember that in the story above, you couldn’t just go straight into the bank vault to retrieve your money from the bank. You had to see the cashier first.Well, you had an action in mind, but you had to convey that action to someone, the Cashier, which in turn communicated (in whatever way they did) with the vault that holds all of the bank’s money.                                                                                                                 The Cashier and Vault communication!The same may be said for Redux.Like you made your action known to the Cashier, you have to do the same in your Redux application. If you want to update the state of your application, you convey your ACTION to the REDUCER — our own Cashier.This process is mostly called DISPATCHING an ACTION.Dispatch is just an English word. In this example, and in the Redux world, it is used to mean sending off the action to the reducers.The REDUCER knows what to do. In this example, It will take your action to WITHDRAW_MONEY and ensure you get your MONEY.In Redux terms, the money you spend is your STATE. So, your reducer knows what to do, and it always returns your NEW STATE.That wasn’t so hard to grasp, right?And this leads to the last Redux principle:To specify how the state tree is transformed by actions, you write pure reducers.As we proceed, I’ll explain what a “pure” reducer means. For now, what’s important is to understand that, to update the state of your application (like you do with setState in React). It is your actions that must always be sent off (DISPATCHED) to the reducers to get your NEW STATE. Never Mutate State Within the ReducersIn very simple terms, a reducer is just a function that takes in state and action, and returns a new state.export default (state, action) => {  return state; };When returning state from reducers, there’s something that may put you off at first. However, if you are already good at ReactJS code, then you should be familiar with this already.You should not mutate the state received in your Reducer. Instead, you should always return a new copy of the state.Technically, you should never do this:export default (state=[], action) => {  return state.push('new value'); };This is preferable:export default (state=[], action) => {  return [...state, 'new value'] };Instead of mutating (or changing) the state received from the reducer, I am returning a new array. This array has all the values of the previous state array, and also appends the ‘new value.’ Thanks to the ES6 spread operator, [...state, 'new value']Every Reducer you write should be a pure function with no side-effects i.e No API calls or update a value outside the scope of the function.Got that?Hopefully, yes.ConclusionWith this analogy, you should now have an idea of what the most important Redux actors are: THE STORE, THE REDUCER, and an ACTION.These three actors are pivotal to any Redux application. Once you understand how they work, the bulk of the deed is done.Happy coding!
Rated 4.0/5 based on 9 customer reviews
An Unforgettable Way To Learn Redux- A Visual Guide

An Unforgettable Way To Learn Redux- A Visual Guide

Blog

React State Management With Unstated

The React community has seen a number of different state management patterns emerging out over the last few years. They range from the very straight-forward setState API to the third-party libraries such as Redux and MobX (there are more, but these are the most widely used), and to the recently updated Context API.Unstated is fairly a new library from@jamiebuilds that’s been gaining some momentum in the community. It leverages the power of React’s Context API to make state management extremely simple. How simple? The tagline of unstated is:State so simple, it goes without saying.After a few hours of working with it, I realized just how simple it is. The API is relatively small, and you can get up and run with it in a matter of minutes. This is a huge positive in a world where third-party state management solutions usually take considerable time to learn.State management primer Before getting started, let’s discuss why we’re really here in the first place. If you’re reading this post then chances are you’re either not happy with the existing solutions out there or you’re looking to try something different. So, let’s explore it.React ships with its own internal state management solution, setState. It’s a straightforward API and a perfectly fine solution for most projects. Most, if not all React devs learn and use setState before anything else (as it should be), you will see many respected voices in the React community saying you not to use anything else until it’s absolutely necessary. I would largely agree.But, eventually, you’ll hit some pain points. In my experience, these pain points are usually in the form of large state objects and event handlers defiling the components, along with the annoying “prop drilling” pattern that inevitably emerges when passing state down to child components.This led us to libraries such as Redux and MobX, which abstract state management away from the component level while still allowing components to “subscribe” to any given piece of state. This mostly solves the problems I mentioned above with setState. Looking further, these libraries are hugely popular and well maintained. Wouldn’t it make sense to double down on one of them and never look back?With great power comes great… boilerplate.I’m sure there’s a larger discussion to be had about the pros and cons of these libraries, but I don’t want to stay too far off our intended path here. I do, however, think it’s important to mention the issue of boilerplate because it’s a real thing and something that has always stopped me about Redux in particular.The code is verbose. The number of files (depending on project structure) you need to interact with just to make a change to a piece of state can be overwhelming. It’s easy to start a new project with good intentions only to find yourself confused by your own folder structure because there is no standard.This is what eventually led me to try unstated.Getting startedYou can install unstated with yarn via yarn add unstated. From there, integrating it into your React application is a breeze. Like I mentioned before, the API is very small, exposing only 3 components:import { Provider, Subscribe, Container } from 'unstated'ProviderThe Provider is very similar to the other Provider types existing in libraries like Redux. You use it at the highest level of your application necessary to provide state to specific components:   ContainerThe Container is used when creating a “slice” of state. You use it in a similar way you would use React.Component:class StateContainer extends Container {  state = {}  updateThis = () => { this.setState({}) }  updateThat = () => { this.setState({}) } }StateContainer will hold a piece of application state, along with any methods that exist to update that state. It’s a beautiful thing really, because everything is encapsulated together.Notice the use of setState here in the handler methods. According to the official unstated docs:setState() in Container mimics React’s setState() method as closely as possible.This means that calling setState inside the Container will cause subscribed components to re-render! You can even use setState as a function:this.setState( prevState => ({}) )SubscribeNow that you know how to create a state. But, how do you pass it to your components? This is where Subscribe comes in. It uses a render prop to pass state and methods into your components:  {container => (    /* access container.state */    /* access container.updateThis() */    /* access container.updateThat() */  )} One interesting point to make about Subscribe is that the to prop takes an array. This gives you the ability to pass multiple state container instances into your components:  {(container, otherContainer) => /* */} An exampleNow that we’ve gone over the entire API (yes, that’s essentially the entire API in a nutshell). Let’s walk through an example together, shall we? I’ve gone ahead and created a sample project here. The project uses create-react-app, styled-components 💅🏻 and rcolor to generate new background colors out of random hexadecimal values.The ContainerInside src/containers/ColorContainer.js you’ll see an encapsulated logic to manage the current state of colors:import { Container } from 'unstated' import rcolor from 'rcolor' class ColorContainer extends Container {  state = {    color: rcolor()  }  make = () => {    this.setState({      color: rcolor()    })  }  active = () => this.state.color } export default ColorContainerEverything inside of ColorContainer is only concerned with the state object. Nothing more, nothing less. Now, any component in the application can “subscribe” to this container, render based on the current state or update that state based on user interaction.The SubscriberIn src/components/App.js you’ll find the application itself:import React from 'react' import { Subscribe } from 'unstated' import ColorContainer from '../containers/ColorContainer' import { Outer, Inner, Button } from './styled' const App = () => (      {color => {      const active = color.active()      return (                              {active}            Another one!                        )    }}   ) export default AppWhen a user clicks on the rendered button, the make method updates the state of ColorContainer with a new hexadecimal value. This causes any subscribed components to re-render, in this case the App component. App will fetch the new value using the active method defined on ColorContainer and pass it to Outer, a styled component that styles its background property using the bg prop.The ProviderAnd finally, src/index.js imports the Provider component from unstated wraps the entire app inside it, allows any child components beneath to access container instances:import React from 'react' import { render } from 'react-dom' import { Provider } from 'unstated' import App from './components/App' render(        ,  document.getElementById('root') )ConclusionIn my opinion, the secret thing behind unstated is how integrated it feels with React itself. It feels like this is how we were meant to manage state in React. Not only that, but its footprint is so small that you can sprinkle it in here or there. You don’t need to think about structuring your application to fit this massive paradigm.I think unstated fits really well in the React ecosystem, sitting nicely between setState and other libraries like Redux and MobX. Consider giving it a try on your next project. You will find that it is a joy to use
Rated 5.0/5 based on 3 customer reviews
React State Management With Unstated

React State Management With Unstated

Blog

Blazor- Building A Faster Web Application Using WebAssembly

Today we are going to look at a new WebAssembly project called Blazor!What it let’s you do is to build a website in C#, compile that into WebAssembly and then have the WebAssembly render your page on the website!What’s the big deal about it? you work with C# only! bye bye JavaScript!Don’t attack me yet folks, I am a fan of JavaScript myself and I don’t think it is going to go anywhere anytime soon.                                                                        (image from: https://gph.is/2GLQPhk) What’s this WebAssembly?Here is the definition from https://webassembly.org/"WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.”Do browsers support this yet?Yes, most major browsers support WASM 1.0 at the moment.                                                                                           WebAssembly 1.0 has shipped in 4 major browser engines. (That Icon is Edge btw ;)) What does WebAssembly mean for Web Platform?In short, this is HUGE!                                                                            WebAssembly has “HUGE” implications for the web platform (image from: https://gph.is/1URUQiq) WebAssembly has huge implications for the web platform. It gives us the possibility to run the code of multiple languages on the web, with Native Speed!As of now, WebAssembly is not intending to be a JavaScript competition, and it is designed to be a complement and run side by side with JavaScript using WebAssembly API’s that provide access to JavaScript APIs.What’s this Blazer framework?Blazor is basically an SPA framework, but not a typical one like Angular or React that uses JavaScript or TypeScript. This one is built on .Net that runs in the browser!                                                                   You can now run .Net in the browser! (image from: https://gph.is/1brOPam) How to run a .Net in the browser?We can run a .Net in the browser using WebAssembly. Basically, we use a .Net runtime called Mono that most of you might have heard. We compile it to WebAssembly, and then run the compiled binary in the browser!Getting started with the projectAlright enough with the into, now let’s get to it.To create your first Blazor project you need to install the following tools and SDKs first:Download and install .NET Core 2.1 SDK (install the latest version).Download and install Visual Studio 2017 (install the latest version) and make sure that you select the web development stuff while going through the installation wizard.Download and install the Blazor Language Services extension from the Visual Studio Marketplace.                                                                              ASP.NET Core Blazor Language Services After installing all that, you can open Visual Studio and go to File > New Project and select Asp.Net Core Web Applicant.Then in the next dialog, you should be able to see “Blazor” along with other web projects. Select Blazor here. This will create your first Blazor WebAssembly project. So select that one!                                                                               Select “Blazor” as your Web Application project type That’s it. this should create your first Blazor WebAssembly project.If you look at your solution explorer you should see something like the following. Now just press F5 and you should be able to see the project running in your browser like the following:                                                                            Running the Blazor project in the browser! A quick look into the codeIf you click around in this basic scaffolding project, you will see that it does a couple of basic things. It has a Counter page that simply just adds to a counter value and displays it and the other page is rendering a grid on the page. Now, let’s look at what is on the Counter page.The Counter page:If you open the Counter page, you will see how this project is doing the same thing JavaScript used to do with C#:@page "/counter" Counter Current count: @currentCount Click me @functions {     int currentCount = 0;     void IncrementCount()     {         currentCount++;     } }The front end for this Counter component is just regular Html stuff. Also, the logic is added using the good old Razor syntax. All this Html and the C# stuff will be converted into a component class when we build the project. When we build the project, the name of the generated .Net class will be the same as the name of the .cshtml file.All the members of this “Counter” component class present in the @functions block, component state (properties, fields) and methods can be specified for event handling or for defining other component logic.How does Routing Work?If you look at the top of the “Counter.cshtml” you can see the @page directive that specifies that this component is a page to which requests can be routed. That means any requests that are sent to “/Counter” will be handled by this “Counter” component. If you don’t have this “page” directive at the top of the component, that component will not handle any requests at all on its own but that component can be used by other components as a subcomponent.A good example of components without routes would be the components under the “shared” folder in this project.How do I add a new component?It is super easy…It is very simple. Under the pages folder, create a new .cshtml file and add the route you like at the top of the page like the following:@page "/test" test pageThis means that our route for the new component is “/test”Then under the “shared” folder, just open the NavMenu.cshtml to add a new menu item for this new component like the following:     WebAssemblySample                                                         Home                                                         Counter                                                         Fetch data                                                         test                         @functions {     bool collapseNavMenu = true;     void ToggleNavMenu()     {         collapseNavMenu = !collapseNavMenu;     } }That’s it! Now, if you press Ctrl + F5, you should be able to see the new Menu and navigate to the new component you created:                                                                                                                                      Adding a new Component in Blazor How do I deploy this Application?Deployment for this application is similar to the deployment of regular Asp.Net Core application. Just right-click on the project, select “Publish” and follow the wizard to deploy your application to Azure.                                                            Deploying Blazor WebAssembly application to Azure And there we have our first Blazor WebAssembly project built and deployed to Azure.Project Source Code:You can find the source code of this project on the following GitHub repository if you want to clone and play around: https://github.com/aramkoukia/blazor-webassembly-sample
Rated 4.5/5 based on 12 customer reviews
Blazor- Building A Faster Web Application Using WebAssembly

Blazor- Building A Faster Web Application Using WebAssembly

Blog

Follow Us On

Share on