Building Dapps with React

Rate this content

Decentralized apps (dApps) are continuing to gain momentum in the industry. These developers are also now some of the highest paid in the entire trade. Building decentralized apps is a paradigm shift that requires a different way of thinking than apps built with traditional centralized infrastructure, tooling, and services – taking into consideration things like game theory, decentralized serverless infrastructure, and cryptoeconomics. As a React developer, I initially had a hard time understanding this entirely new (to me) ecosystem, how everything fit together, and the mental model needed to understand and be a productive full stack developer in this space (and why I would consider it in the first place). In this talk, I'll give a comprehensive overview of the space, how you can get started building these types of applications, and the entire tech stack broken apart then put back together to show how everything works.

30 min
22 Oct, 2021


Sign in or register to post your comment.

AI Generated Video Summary

The Talk discusses building decentralized applications (DApps) with React and explores the benefits of smart contract technology. It highlights the characteristics and infrastructure of Web 3 applications, including decentralized indexing, off-chain data storage, and decentralized file storage. The Talk also covers identity in Web 3, with a focus on self-sovereign identity and the use of blockchain for identity verification. The process of building a DApp with React and Hard Hat is explained, along with deploying contracts and interacting with them. Overall, the Talk provides insights into the world of DApps and the technologies involved.

1. Introduction to Building DApps with React

Short description:

I'm really excited to be here and happy to be talking about something that I am extremely interested in. I want to share some of the ideas I've learned here with you and show you how to get up and running with a stack that might be brand new to you if you've never looked into the blockchain space. My talk is called Building DApps with React. We are going to be building a DApp. A decentralized app is an app that runs in the decentralized web. These decentralized applications bring use cases that we've never seen before.

Thank you for that amazing introduction. I'm really excited to be here in person in London. We had React advanced a couple of years ago. And, of course, it's been a while since we've had any in-person events. Here especially. But really, maybe in the last month or so we started seeing them come back. So I'm really excited to be here and happy to be talking about something that I am extremely interested in.

So, yeah, I hope you learned something here. So my name is Nader. I'm a developer relations engineer at Edge and Node. Edge and Node is a company that kind of falls into the blockchain, crypto, web three categories. And it was really only created back in February. So it's a really new startup. But during the last six months or so since I joined, coming from kind of a traditional background, I've learned a lot. And I want to kind of share some of the ideas I've learned here with you and hopefully make them as concise as possible and just show you how to get up and running with kind of a stack that might be brand new to you if you've never really looked into the blockchain space.

So my talk is called Building DApps with React. And we are going to be building a DApp. And DApp is an acronym for decentralized app. And a decentralized app is an app that kind of runs in the decentralized web. And when we talk about a lot of these terms that I'm gonna be speaking about in just a moment, you've probably heard a lot of hype recently around Web3, and decentralized apps, and decentralization, and crypto, and all this stuff. Well, as a developer, I've been speculating in crypto since like 2015 or so, just buying and selling tokens and stuff. But I never really looked at it as anything more than just a financial tool or something to kind of gamble on, essentially. I never really understood that people were building software with it. So I have been, I would say, writing code for like 10 years. So how could I have not really looked into this any further until maybe a few months ago? I really don't know. But once I started kind of diving into some of these platforms and protocols, I realized that what most of these teams are trying to do is build new ways for us to build applications to power the web. And the changes that are trying to be made happen or some of the things that are taking place are kind of a lot different than anything we've seen before. So often you hear people bucketing these ideas into something that people are calling web three, when in reality we're just kind of building out decentralized applications. But the applications that we're building again are so much different than the ones that we've done in the past. So they kind of bring use cases that we've really never seen before in the past.

2. Understanding Web 3 and Decentralized Applications

Short description:

Web 3 is the stack of protocols that enable applications to be fully decentralized, or they allow developers to build fully decentralized applications. It's kind of more of a spectrum that we're trying to get to. So, let's dive deeper into this, and then we're gonna start writing some code.

So I think it does make sense to kind of try to categorize these types of applications as something different. A lot of the objectives that people are going for are a lot different than some of the things that we've seen in the past. I think one of the main areas of concern that people have are around things like data harvesting and how social networks work today and how attention is a currency that is kind of used against users. And we have things like, you know, the surveillance essentially, kind of like when we're interacting with applications, they're tracking us and all this stuff. So how can we build out applications that allow developers to get paid, that allow companies to make money, but they take away some of these negative constraints? So Web 3 is kind of trying to accomplish that, you could think, you could say. And really, if you really want to boil it down to something extremely basic, you could kind of say that Web 3 is the stack of protocols that enable applications to be fully decentralized, or they allow developers to build fully decentralized applications. Now, when you hear about decentralized applications, it's kind of like, you know, the end goal. I don't think that everything can be built in this way or everything should be built in this way. It's kind of more of a spectrum that we're trying to get to. So, let's dive deeper into this, and then we're gonna start writing some code.

3. Benefits of Smart Contract Technology

Short description:

The internet has thrived due to common protocols that we can use globally. However, native payment and state functionality were missing until the implementation of smart contract technology on blockchains. Building complex centralized infrastructure was the solution to overcome these limitations. With smart contract technology, developers can programmatically enable digital scarcity and exchange assets. Additionally, building databases traditionally requires significant effort and has drawbacks like single points of failure. Solutions like Amplify and SuperBase provide easier ways to build databases.

So, when you think of the internet and the way that we build apps today, a lot of the reason that the internet has thrived and become so successful is that we have common protocols that we can all use around the world, and we can just expect them to work. So, we know FTP, we know SSH, we've interacted with all these different protocols, if we put our application up, we can be guaranteed that our users can access it from anywhere in the world with HTTP, and there's not gonna, we don't need any centralized intermediary in order for that to happen. It just works. So, these protocols are widely adopted. They're not subject to change, and they're very well understood by developers, and we just take them for granted at this point.

But there were a couple of pieces of functionality that were left out, or that we just did not have access to up until really the implementation and the evolution of smart contract technology on blockchains, and that was native payment in native state. So, what do we do to get around this? Well, we built out massively complex centralized infrastructure to fix this. When you think about payments, how do payments work? If a person in the United States decides that they wanna wake up one day and send money to someone in another part of the world, what does it take to do that, to make that happen? Well, if this person doesn't already have a bank account or an ID, they first have to go get paperwork, go to some authority, receive an ID. They need to go then to a bank, they need to take money from another place, they need to open an account, they need to provide all this information to this bank, put the money there, and then they may or may not get a bank, depending on where they live because there's still over 70 countries that don't allow women from certain categories or certain communities to even open a bank account by law. But let's say that they live in a place that allows them to open a bank account. They open that bank account, they then go to their computer, they create an email address, they then go to PayPal or Stripe or whatever, they then create an account, they then link their account. Maybe they try to link their account but they get blocked for whatever reason. So all this stuff has to go through for this one person to do it, and then the other person has to do the same thing on the other side of the world. And then maybe the two things that they decided to use are not compatible because PayPal doesn't work in their country. So in order to get around this, we built more and more complexity. So we have more people, more companies trying to solve this problem. Well, with smart contract technology and blockchains, you can programmatically enable digital scarcity resulting in assets that people are willing to exchange for other things, aka tokens or currency. So we kind of have now ability to build this as developers. And we can do it in a couple of lines of code. We can actually send transactions between parties in just a couple of lines of code. That's why this is revolutionary. That's why things are happening here. Now, what about payment? I mean, what about state? Well, right now, if we want to build a database, how does this happen? Well, typically, we'll spin up a database in our living room, our garage, or maybe in AWS. Now, this is great because it enables anyone to build a database without a ton of work. But there are drawbacks here as well. First of all, this database is a central single point of failure. So if something happens to our database, then our application is down. Also, when you think about how applications are accessed from around the world, if you want to have caching or anything like that set up, you typically have to have edge networks and all of these things working. So again, I'm kind of skimming over all the details around an implementation, but if you've ever used something like AWS and you have spun up a database, you know how complex it actually is to build all this from scratch. Therefore, you now have really great solutions out there, like Amplify, like SuperBase.

4. Characteristics of New Types of Applications

Short description:

Blockchain technology and smart contracts enable you to programmatically have distributed global state that anyone can read, and that is trustless. So, what are the types of characteristics that you might expect from these new types of applications?

They're abstracting away a lot of this, and Firebase. We just had a talk yesterday with SuperBase, and they said a lot of the reason that people were using Firebase is not because they actually liked the implementation, but it's so easy to spin up. Because it is complex to get all this stuff set up. These are all basically trying to fill in the gap that we do not have native state within the internet. Blockchain technology and smart contracts enable you to programmatically have distributed global state that anyone can read, and that is trustless. We can assume that if it is there, that it's actually the right data and anyone can access it from around the world, and anyone can verify it. So, with that being said, what are the types of characteristics that you might expect from these new types of applications?

5. Building with Web3 and Decentralized Applications

Short description:

We now have a new way of building things with web three and decentralized applications. Decentralization is a key characteristic, ensuring distributed, trustless, and robust infrastructure. Open and public back-ends allow for collaboration and sharing of infrastructure. This is already happening, with applications being built on decentralized exchanges, DeFi, and NFTs. The categories of applications include DeFi and stable currencies, decentralized web infrastructure protocols, and play-to-earn gaming.

I think it's more like we now have a new way of building things again. We have things that have evolved over time, giving us more and more tools to accomplish the job that we're trying to accomplish. So, I'm not saying you should use web three or decentralized applications to build everything, but now you have a new type of application that you can build, and we can also improve on some of the old ones, but some of the old ways of doing things are perfectly fine and we shouldn't reach for these tools.

But when you think about a decentralized application, decentralization is in the discussion because it often has to do with every part of what we're doing. We're decentralizing the web infrastructure, but we're also decentralized ownership. We're decentralizing data. We're making everything more equitable and more distributed, and a lot of the things that come from that are these other characteristics. So, one of them that is very important is this idea of distributed, trustless, and robust infrastructure that just doesn't go down. So, if you have a single server running somewhere and it goes down, your application can't be built. But if you have this application replicated across hundreds or thousands or tens of thousands of nodes, that if a node or if 25% of the network goes down, your application still runs. There is no single point of failure. That's why when you kind of think about us as software developers, to me this is what stands out the most. If I can build on a back-end that really never goes down, I don't really have to worry about a lot of the things I kind of have to worry about today.

Another thing that excites me as a developer is this idea of open and public back-ends. Essentially you have open source code today. What if we had open-source infrastructure that anyone could build upon? So I build an app, I deploy it to the network. Anyone that can write front-end code can now build an interface on top of that and we can all now compete and we can kind of share infrastructure and we can use this infrastructure as building blocks to kind of make better and better projects. And this is already happening. This isn't kind of theoretical. We're already seeing this start to take shape. Dozens of applications are being built on different decentralized exchanges, DeFi. You're starting to see, of course, NFTs have been in the news and stuff. I think it's kind of just the evolution of this idea and I think we're gonna start seeing better and more real-world use cases in the future and that's kind of a thing that I'm excited about. So, what are the actual categories of applications? Well, DeFi and stable currencies are interesting because they allow anyone that can write code to build financial applications. Decentralized web infrastructure protocols. I work on a protocol called the Graph protocol that enables developers to build GraphQL APIs on top of blockchain data. I'm gonna cover that in just a little bit, in just a moment. Play-to-earn gaming. So, Axie Infinity is a Web3 game. They've done over $750 million in a single month in transactions.

6. Building DApps and Web Infrastructure

Short description:

They've done over $750 million in transactions. Decentralized autonomous organizations, digital art, tokenizations of physical assets, transferable content ownership. Web3ification of Web2 applications. and Audius are examples of platforms enabling users to monetize their content. The focus is on building decentralized applications and web infrastructure. The graph protocol is used for indexing and saving data on blockchains.

They've done over $750 million in a single month in transactions. It's like Fortnite except for 100% of the money going to the platform, 95% of the money stays with the users. So, if I put in $1,000 into the platform, or $100, I can expect that when I decide to stop playing that game, I can get some of that money back. And, again, it makes a lot more sense to me.

Decentralized autonomous organizations, digital art, tokenizations of physical assets like real estate, kind of opening the market for more people to participate, lowering the barrier to entry for people to buy into financial markets that they were priced out of in the past. And, I think this idea of transferable content ownership, applying Web3ification to Web2 is really interesting. So, right now on YouTube, if I upload a video, I have no control over that. I can lose my password or someone can hack my account and it can all go away. This happens so many times. Also, if I wanna build out my own front end on top of this, I have to use their APIs, and if I use them wrong, I might be limited by that, or they might not even provide the API that I want. What if all of our data was there for us to use forever? We don't have to ask anyone for it. And, other people can also build front ends on top of this, and interesting stuff like that. So, I think we're gonna see, and we've already started seeing the Web3ification of Web2 applications. is a blogging platform that allows users to do all types of financial types of stuff within their blog posts. So, you've seen people doing fundraising, you've seen people do NFT launches within their blog posts. Recently, someone did a blog post where they wanted to kind of create a movie. They raised over $3 million directly within their blog post. They also give tokens to the writers. So, if you're writing stuff, you actually make money. That's pretty interesting. Music, there's a program called Audius, or an application called Audius that is a decentralized Spotify that allows not only the content creators to make more money, but you as a user, if you create a playlist that people really like, then you actually earn money for that. Instead of the platform, like Spotify, taking all this money, you're actually participating and you're getting paid for it, and I like that. So, with that being said, we want to focus on building and we want to focus on the web infrastructure. Let's take a look at a few of the pieces for building a decentralized application. So, the graph protocol is what I work with at Edge and Node. When you think of a typical database, it's optimized for indexing and querying. Blockchains are not optimized for querying. They're only optimized for indexing. They're not really even optimized for indexing. They're only optimized for transactions, for saving data.

7. Infrastructure and Identity in Web 3

Short description:

Blockchain data is saved in blocks with a focus on high transaction speed, low latency, and low costs. The Graph Protocol allows decentralized indexing with incentives for data accuracy. Ceramic Network is a decentralized network for off-chain data. Livepeer is a successful decentralized live streaming platform. IPFS and RWEV provide decentralized file storage. Radical is a decentralized version of Git. Web 3 applications challenge traditional notions of identity.

So, blockchain data is saved in these blocks over the course of days, weeks, months, years, whatever. And it's really, the focus is to kind of have the most transactions per second, the lowest latency, and the least expensive transaction costs. For you to query this data, though, you typically can only read single pieces of information at a certain point in time. If you want to get all of this data and perform queries, like relational, and all this other stuff that you typically need for a performant application, you have to index that data in the database, then build out your own API endpoint, therefore breaking the important security principles of decentralization in the first place.

The Graph Protocol is a decentralized network that allows developers to build GraphQL APIs that kind of do this indexing, but they replicate it across the entire network, and they also provide incentives for your data to be correct. So, therefore, if you provide the wrong data, you get penalized in the form of a money penalization, so you kind of are losing money. So that's one piece of infrastructure.

Ceramic Network is interesting. It is a decentralized network, but it's for off-chain data. So you don't wanna store everything, probably, on a blockchain. You might wanna have information that is, of course, available to save and read for free. So if you wanna save something and you don't want it written with a transaction cost, you might use something like the Ceramic Network.

You have video streaming. Livepeer is a very, very successful decentralized live streaming platform. It's anywhere between 10x to 50x or more, less expensive than using something like AWS. The reason that it is less expensive, it uses people's computers that are already running, doing other stuff to offload the processing for videos to a decentralized network of people that decide to buy in, and the people that are running these nodes get paid for their processing. But it's more efficient because there's more participation and it's utilizing the compute, I would say, more efficiently than you might see in a centralized network.

For file storage, like videos, images, and things like that, you have IPFS and you have RWEV. There's a handful of other ones as well. RWEV is extremely interesting to me because it allows you to store a file forever. So if you wanna store an image and you wanna read it 10 years from now and you don't wanna pay any type of hosting fees or something like that, then RWEV is a great place to do that. I'm experimenting right now writing a blogging platform that saves the text into RWEV and kind of stores the anchor of the ID to retrieve that text on a blockchain like Solana, therefore building a censorship-proof forever blog that I never have to pay hosting for. It just lives forever.

For Git, Git itself is decentralized, but GitHub is not decentralized. So, Radical is an attempt to build a decentralized version of Git. And it actually is already there and working. I would definitely check that out.

So, I think the most, one of the most interesting differences between web-2 applications and web-3 applications is how we think of identity. Identity to us is actually our, you know, name and email address and phone number and all this shit that we don't really, probably shouldn't be handing over to all these people. We're handing it over hundreds and thousands of times within our lives.

8. Identity and Blockchain for Web-3

Short description:

When working with web-3, you identify yourself via an address and wallets. Wallets allow you to create a wallet using a seed phrase, derive private and public keys, and then derive your address. This enables you to transfer your wallet anywhere in the world and sign transactions using public key encryption. Sign in with Ethereum and IDX offer self-sovereign identity, allowing you to control and attest information to your address. To build an app, you need a blockchain, with the Ethereum Virtual Machine being a popular choice that can be applied to multiple blockchains.

Why isn't there a better way to identify ourselves that is anonymous for most use cases? And sometimes we still wanna give people our address, right? Because they might wanna ship us something eCommerce. So, let's have more control over that.

Well, when you're working with web-3, you typically are gonna be identifying yourself via something called an address. And your identity is typically gonna be derived from that address in a few different ways. And the way that you do that is via, right now, something called like wallets. The wallets have a couple of different things that you can do with them, but essentially you can create a wallet either via getting a seed phrase from one of the wallet providers, either directly through the wallet or kind of like doing it yourself using a framework like web3.js or ethers.js.

But the idea with the wallet is this. You're given a seed phrase. You can then mathematically derive a private key from that seed phrase. You can then mathematically derive a public key from the private key. And then you can mathematically derive your address from that public key, meaning that you can transfer your wallet anywhere in the world. All you need is that seed phrase. So anytime you wanna log in anywhere in the world, you don't really have to kind of like transfer login information. If you have that seed phrase, you can kind of like go in and get your information. And therefore you can kind of like sign transactions and parse those transactions using public key encryption. And it allows you to do really interesting and a lot lower, I would say, complexity for building authentication mechanisms.

And one of the things I'm really excited about is this idea of like sign in with Ethereum that kind of leverages this. And IDX is an identity protocol. So let's say you do wanna attest some information to your address about yourself. You can do that in a decentralized way that you control all of that information. It's kind of like this idea of self sovereign identity. You can decide what to put there and the application typically doesn't ask you for that information. It'll ask for the pointer, and it will look in this place, and then it will decide, okay, I need this information based on what you've stored there. And then you can go back and change that however you would like.

And then the last thing you would probably need to build an app is, of course, the blockchain. There are a handful of ones that I'm kind of interested in right now. I think the one that most people start with is the Ethereum Virtual Machine, and Ethereum Virtual Machine is the implementation of Ethereum, but can also be applied to a handful of other blockchains. It's kind of like the React of blockchain development. If you learn EVM, you can write for a Polygon, Optimism, Arbitrum, you know, Ethereum, of course, but also Cello, Avalanche. There's like a dozen or so popular smart contract blockchains that you can build on once you learn EVM.

9. Building a DApp with React and Hard Hat

Short description:

So Web3 could be thought of as the typical infrastructure that we're used to, but decentralized, and we now have smart contracts. So let's build a dapp. We wanna have our client framework, our Ethereum development environments, our Ethereum client library, and our wallet. One of the most loved projects in the EVM ecosystem is hard hat. For this demo, we're gonna use React.js, hard hat, Ethers, and MetaMask. We're gonna build out an application called ReactDApp.

So Web3 could be thought of as the typical infrastructure that we're used to, but decentralized, and we now have smart contracts, so we still need all these things like compute identity, data, storage, web hosting, but we now have additional tools at our disposal that allow us to do more things.

So let's build a dapp. So when we're starting with the most basic application we might wanna build, we just wanna think of these main things. We wanna have our client framework, which could be something like React, we wanna have our Ethereum development environments, and there is a really great development environment that we're gonna look at in just a moment that kind of does everything that you need. We also need our Ethereum client library, and we need our wallet. So the wallet is the identity, the Ethereum client library could be thought of as something like Axios or Fetch or GraphQL Apollo. This sends API requests via our PC endpoints to our network that we're interacting with.

So I think one of the most loved projects in the EVM ecosystem is hard hat. Hard hat is just really, really, really great to get up and running. You can spin up an entire blockchain network locally in just a couple of seconds, and we're gonna do that. So for the stack that I'm gonna be using today, we're gonna be using actually React.js, hard hat, Ethers, and MetaMask. I do like Next.js actually for most of my applications, but I think for this demo it's more simple to solve with just React. So what we're gonna do is build out an application. So can everyone see that pretty good? Okay, cool. All right, so I have a app called ReactDApp. And I'm gonna go ahead and open this up. Sorry, is this gonna be a long demo or is it a short demo? How much more time do we have? Five minutes? You're already a bit over time actually. Oh really? Yeah, it's a 20-minute slot, man. Oh, it's a 20-minute slot? Yeah, yeah, yeah. I can knock this out in about five minutes. You think that's okay? Um, I think that's all right. We'll just cut in the Q&A a little bit. Okay, we can cut the Q&A, that's fine. I'll just stand outside and answer questions. Okay, so, sorry about that. Yeah, I didn't realize that. I thought it was a 30-minute slot. So, we have a React application here. And, let's see here. Okay.

10. Setting up Hard Hat and Deploying the Contract

Short description:

We're in a React application and have added Hard Hat as our Ethereum environment. After setting up the project, including the contracts folder and Hard Hat configuration, we compile our smart contract into ABIs. We then create an Ethereum node with 20 accounts, each with 10,000 ETH. By importing the private key and deploying the contract to localhost, we can interact with it. Our application is deployed, and we can start it by running npm start. In app.js, we import the necessary components and set the contract address for basic interaction.

Whoops, that's not it. Okay, I'm sorry. I actually had, okay, here we go. So, anyway, we're in a React application. I have just run npx create React app. We have our scaffold there. What I want to do is I want to add Hard Hat, which is our Ethereum environment. So, I can run npx Hard Hat. This will walk us through a Hard Hat setup. So, I'm gonna say I want a basic sample project, the project root, and a git ignore. We'll go ahead and do that. And this will go ahead and create a contracts folder with our smart contracts, a Hard Hat configuration, which has our configuration for our project here. And I want to go ahead and set our path, for we compile our smart contract into something called ABIs. You could think of ABIs as something like a GraphQL query. It sends the information across the network for us to interact with our endpoint. So now that we have that, we can go ahead and create our Ethereum node. So, I'm gonna go ahead and run npx Hard Hat node. And this is gonna run an Ethereum node, and it's gonna give me 20 accounts, each one with 10,000 ETH. So, I'm gonna go ahead and copy this private key, and we're gonna go into Chrome, and this private key is kind of the private key that I mentioned that can be your identity. You can either get it from a seed phrase, or you can kind of get it from your local environment, I guess, when it spins it up. So, what I'm gonna do is I'm gonna import account, paste in the private key, and we now see that we have 10,000 ETH. I wanna now deploy this contract to local host, and if I go here, we should see that this is deployed locally. All right, so our application is deployed. Now, let's go ahead and run this. I'm gonna say npm start, and I'm gonna copy this address, and we're almost done. I'm just gonna go ahead and go to app.js, and we're gonna do our imports. We set our address here, and we're kinda just gonna be interacting with a really basic smart contract updating, I would say, a value that I'll show you in just a moment. We have our contract address. This was given to us when we deployed our scripts. So just by running it, we're given all of this here.

11. Interacting with the Contract and Building the App

Short description:

Next, we create the initial state and interact with a basic contract. We import the ethers.providers API and access the window.ethereum variable. With the contract deployment address, we call functions within the contract. We build the UI and test it by fetching and setting the greeting. We can now interact with our wallet, pay for the transaction, and see the updated value. In just a few minutes, we've built a basic app that interacts with a smart contract.

Next, I want to go ahead and create some initial state. So the contract that we're interacting with is pretty basic. We have a greeting, and this should look very familiar if you've done TypeScript before. We have a state variable called greeting, we have a constructor where we set the greeting, and we have a function that returns the greeting, and we have a function that updates the state by setting the greeting. So we can either return the greeting or set the greeting. So let's go ahead and open up app.js again. We're gonna go ahead and create a function for connecting our wallets. We're gonna have a function for fetching the greeting. And I'm gonna just walk through one of these because we're almost done on time, we're over on time, and I have a function for setting the greeting. So just to kind of give you a quick overview of what it looks like to interact with the contract, we import the ethers.providers API, I guess you could say from ethers.js, and we're able to access this variable called window.ethereum, because if you have a wallet installed in your browser, it injects this global variable called window.ethereum that you can access. We then get a reference to our smart contract deployment by using the address of our contract deployment, the API that was created when we compiled our smart contract in the provider we just created, and now we can call functions within our contract. So here we're calling contract dot, whatever function we wanna call. And then finally we can go ahead and build out our UI. And whoops, just gonna do it here. And we can go ahead and test this out. So our UI isn't nice but it's just, you know, it's just gonna work. Something basic. What I can now do is click fetch greeting and we should go ahead and be able to get the greeting from the chain, hello hard hat, and if I go to here, you can see that this contract call was made, and then I can set the greeting to hello react advanced. And this should, yeah, this should be interesting because we should be able to now interact with our wallet. So we can choose the address we want to interact with. We can now pay for this transaction because we're writing something to the chain. We can confirm that. And now if I refresh, the value should be the updated value. And we've built a really basic app that interacts with a smart contract, and we did it in like, what, three or four minutes or two minutes, maybe one minute.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.
In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick
easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data
use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time

React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?
There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.
Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.
You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.

React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents
- The different kinds of React application tests, and where component tests fit in
- A mental model for thinking about the inputs and outputs of the components you test
- Options for selecting DOM elements to verify and interact with them
- The value of mocks and why they shouldn’t be avoided
- The challenges with asynchrony in RTL tests and how to handle them
- Familiarity with building applications with React
- Basic experience writing automated tests with Jest or another unit testing framework
- You do not need any experience with React Testing Library
- Machine setup: Node LTS, Yarn