Flow

flow

Flow is a permissionless layer-1 blockchain built to support the high-scale use cases of games, virtual worlds, and the digital assets that power them. The blockchain was created by the team behind Cryptokitties, Dapper Labs, and NBA Top Shot. One core attribute that differentiates flow from the other blockchains is its usage of capability-based access control. At its core, capability-based access control creates tokens of authority to give stakeholders selective access to certain resources without sharing everything. But why is this important for you as a Flow developer? With capabilities, you can define a user’s granular-level access privileges. So, if you’re building a music app and want to give the capability to access top playlists to only premium users, you can control that very easily with the built-in capabilities functionality of Flow. ( ) Source What is Blockchain authorization? Blockchain authorization is the methodology by which access to information and execution permissions are granted on a blockchain system. Several operations that a user may need to perform within a blockchain may include the following: Creating new smart contracts Updating smart contract code Executing smart contract functions Being a validator node Updating smart contract data If the methodology used to manage the execute permissions of the above operations is not fault-tolerant, then it could be a huge security risk for the application. There are several major types of authorization that have the same objectives but slightly different implementations. Access Control Lists (ACLs) Access Control Lists (ACLs) refer to the authentication mechanism that works on maintaining individual lists for managing access to different objects. ACLs are like guest lists for a resource. Those participants that are on the guest list of a certain object are allowed to access, and others are not. Role-based access control (RBAC) Role-based access control refers to the idea of assigning permissions to network participants on the basis of their role within an organization. The access rules are mapped to the roles rather than the individual identities. This is the most common form of authorization used in popular products like AWS. Capability-based authorization A capability is an unforgeable token of authority. In Capability-based authorization, your identity does not matter. If you receive an access token from the owner/admin that grants you the capability to access a resource, and you are able to execute that capability, then you will have access. At runtime, the application does not check what your identity is but only that you have the capability to access the requested resource. ACLs versus Capability-based authorization There are certain drawbacks to implementing ACLs, especially in the context of decentralization, which we’ll discuss below. Ambient Authority problem Let’s say that, as a user, you have received several different types of access and privileges to an app on your operating system. At some point, you request the app to fetch certain data for you. You would want to make sure that the app fetches only the data that’s absolutely necessary and doesn’t access anything else. However, in the case of ACL systems, there is no way to make sure this happens since the app has “ambient” authority. This can only be solved by using capability-based security systems. Watch to learn more. this video Confused Deputy problem Let’s say there’s a program A requesting a program B to perform certain actions. There might be instances where only program B has access to perform some of those actions, but program A does not. Program B still performs them because it didn’t double-check. In this case, program B was tricked into misusing its privileges by program A. This can be solved by using capabilities. Watch to learn more. Here’s how the company 25 years ago. this video Tymshare faced this problem ACL attack vector Because ACL lists are usually maintained with a centralized owner, it is prone to malicious updates at any time. Using capabilities takes away the power of performing malicious updates from a centralized owner and hence makes the system secure from the large ACL attack vector. ( ) Source About Capabilities A capability (also known as the ‘key’) is a hash that designates both the resource and access to it. This is also the model implemented in Bitcoin, where “your key is your money,” and in Ethereum, where “your key is gas for EVM computations.” In the Flow blockchain, “your keys are your data,” and hence, data access is controlled directly by keys instead of identities. By tying access to the key, capability-based models push security to the edge, decentralizing large attack vectors. Capabilities also make it very easy to write code that defines security privileges in a granular fashion. There are two major types of capabilities in Flow blockchain: Public capabilities Public capabilities are created using public paths and hence have the domain “public”. After creation, users can access them with authorized accounts (“AuthAccount”) and public accounts (“PublicAccount”). Private capabilities Private capabilities are created using private paths and hence have the domain “private”. After creation, they can only be accessed by authorized accounts (“AuthAccount”) and not by public accounts (“PublicAccount”). 3 Tenets of Capability-based Security — Capability-based security always has an unforgeable key to go with a particular access. This means that just the identity of a participant is not enough to get access. Encryption-based — Capability-based security is totally decentralized. This means that the success of the security system is not dependent on a single owner. Decentralized — It is easier to define fine-grained access to data and resources using capability-based security. Granular Creating a capability in Cadence Cadence is the programming language used to create Flow contracts. Below, we’ll talk about the code used to create capabilities in Cadence. Creating capability using a link function The link function of an authorized account (“AuthAccount”) is used to create a capability. fun link<T: &Any>(_ newCapabilityPath: CapabilityPath, target: Path): Capability<T>? is the public or private path identifying the capability newCapabilityPath is any public, private, or storage path that leads to the object that will provide the function defined by this capability target is the type parameter for the capability type T The above function will: return nil if the link for a given capability path already exists return the capability link if the link doesn’t already exist Removing capability using the unlink function The unlink function of an authorized account (“AuthAccount”) is used to remove a capability. fun unlink(_ path: CapabilityPath) is the public or private path of the capability that should be removed path Other important functions getLinkTarget This function can be used to get the target path of a capability. fun getLinkTarget(_ path: CapabilityPath): Path? getCapability This function can be used to get the link to existing capabilities. fun getCapability<T>(_ at: CapabilityPath): Capability<T> check This function is used to check if the target currently exists and can be borrowed. fun check<T: &Any>(): Bool borrow This function is used to borrow the capability and get a reference to a stored object. fun borrow<T: &Any>(): T? Code examples of creating a capability with Cadence We will follow a simple example where: Step 1: We will create a smart contract with a function as a resource. Step 2: We will access the resource. Create a capability to access the resource in that smart contract. Create a reference to that capability using the borrow function. Execute the function resource. Step 1: Creating a car smart contract Explanations are in the comments below: pub contract Car {
    // Declare a resource that only includes one function.
    pub resource CarAsset {
        // A transaction can call this function to get the "Honk Honk!"
        // message from the resource.
        pub fun honkHorn(): String {
            return "Honk Horn!"
        }
    }
    // We're going to use the built-in create function to create a new instance
    // of the Car resource
    pub fun createCarAsset(): @CarAsset {
        return <-create CarAsset()
    }
    init() {
        log("Creating CarAsset")
    }
} Step 2: Accessing the honkHorn() function in the CarAsset resource of Car smart contract The code below includes all three steps: Creating the capability to access the resource from CarAsset Creating a reference by borrowing the capability Executing the HonkHorn function Explanations are in the comments below: import Car from 0x01

// This transaction creates a new capability
// for the CarAsset resource in storage
// and adds it to the account's public area.
//
// Other accounts and scripts can use this capability
// to create a reference to the private object to be able to
// access its fields and call its methods.

transaction {
  prepare(account: AuthAccount) {

    // Create a public capability by linking the capability to
    // a `target` object in account storage.
    // The capability allows access to the object through an
    // interface defined by the owner.
    // This does not check if the link is valid or if the target exists.
    // It just creates the capability.
    // The capability is created and stored at /public/CarAssetTutorial, and is
    // also returned from the function.
    let capability = account.link<&Car.CarAsset>(/public/CarAssetTutorial, target: /storage/CarAssetTutorial)

    // Use the capability's borrow method to create a new reference
    // to the object that the capability links to
    // We use optional chaining "??" to get the value because
    // result of the borrow could fail, so it is an optional.
    // If the optional is nil,
    // the panic will happen with a descriptive error message
    let CarReference = capability.borrow()
      ?? panic("Could not borrow a reference to the Car capability")

    // Call the honkHorn function using the reference
    // to the CarAsset resource.
    //
    log(CarReference.honkHorn())
  }
} If you execute the above function, you should see the message “Honk Honk!” in your console. Refer to to learn how to deploy a contract and execute Cadence code. this tutorial Conclusion In this article, we learned the types of blockchain authorization and the added advantage of using capabilities over other methods of authorization. We also learned how to create, execute, and transfer capabilities in Cadence, the smart contract language of Flow blockchain. These learnings will help you as a developer to write highly secure code when building on Flow. In essence, capabilities open up a new paradigm of blockchain authorization, making it very easy for developers to define access at a granular level. The fact that Flow blockchain uses this paradigm for data access makes it one of the most secure blockchain options out there. And as you probably noticed, it is super easy to create capabilities in Flow. I hope that you enjoyed this deep dive into capability-based security in Flow blockchain. You can refer to the on Capabilities to learn more. I also recommend that you get your hands dirty by going through and this . official docs page Flow Docs tutorial on Capabilities Also published . here

Moving to Capability-Based Security with Flow: A Critical Evolution in Blockchain Security

is a permissionless layer-1 blockchain built to support the high-scale use cases of games, virtual worlds, and the digital assets that power them. The blockchain was created by the team behind CryptoKitties, Dapper Labs, and NBA Top Shot. Flow One of the best features of Flow is that it supports the paradigm of resource-oriented programming. Resource-oriented is a new way of managing memory where resources are held “in-situ” by the resource owner instead of in a separate ledger. This is very relevant for managing scarce and unreplicable digital resources on the blockchain. programming In this article, I’ll do a deep dive into resource-oriented programming—and allow you to better manage your resources in your Flow smart contracts. What is resource-oriented programming? In resource-oriented programming, objects are labeled as “resources.” Resources are a collection of variables and functions that only have exactly one copy at a time. Resources provide better composability than EVM and WASM. When something is called a resource, there are very specific rules for interacting with it. The three rules that apply to resources in resource-oriented programming are as follows: Each resource exists in only one memory location - Resources cannot be duplicated. Ownership of a resource is defined by where it is stored - No central ledger that keeps track of ownership. Only the owner of the resource can access its methods. To explain this better; in the real world, if you claim to own a watch, that ownership is proven by the fact that you possess it yourself. There is no central ledger that people refer to check if you are the owner. However, in programming, when we think of ownership, we think of a mapping somewhere in a ledger of the object ID to the owner ID. For example, in the case of ERC721 smart contracts, the ownership of digital assets is stored in a ledger owned by the main smart contract. Flow changes this paradigm of ownership by storing “resources” in the memory location owned by the owner itself (see image below). This means that if you’re holding a digital asset on the Flow blockchain, it is stored in the memory location of the account that you own. This has several benefits, which we’ll talk about in the coming section. Resources in Cadence is the world’s first high-level resource-oriented programming language. , created for Facebook’s now-defunct Diem, is the only other language that is resource-oriented, but it is more low-level. Cadence Move In Cadence, resources are defined using the “resource” keyword. Within a resource, you can define the attributes of the resource, like variables and functions. This definition of a resource now becomes a type and can be used to create objects of that type.\ An example of creating a resource and creating an instance of that resource is shown below: // Declare a resource that only includes one function.    pub resource CarAsset { // A transaction can call this function to get the "Honk Honk!"        // message from the resource.        pub fun honkHorn(): String {            return "Honk Horn!"        }    } // We're going to use the built-in create function to create a new instance    // of the Car resource    pub fun createCarAsset(): @CarAsset {        return <-create CarAsset()    } Destroy function Resources in Cadence can be explicitly destroyed using the “destroy” keyword. The Move Operator (<-) To make the moves of a resource explicit, the Move operator, such as “<-” must be used when: Initializing the value of a constant or variable with a resource Moving resources to a different variable Moving resources to the argument of a function Returning it from a function Code Example of Creating a Resource in Cadence Below is an example of a Cadence script that creates a CryptoKitty collection as a resource and also stores individual Kitties as a resource. contract CryptoKitties {// Accounts store a collection in their account storage  resource KittyCollection {// Each collection has functions to// move stored resources in and out  fun withdraw(kittyId: int): CryptoKittyfun deposit(kitty: CryptoKitty)}  // The resource objects that can be stored in the collectionresource CryptoKitty {}} transaction(signer: Account) {// Removes the Kitty from signer's collection, and stores it// temporarily on the stack. let theKitty <- signer.kittyCollection.withdraw(kittyId: myKittyId) // Moves the Kitty into the receiver's accountlet receiver = getAccount(receiverAccountId)receiver.kittyCollection.deposit(kitty: <-theKitty)} In the above code, we create a KittyCollection resource that has several CryptoKitty sub-resources within it. We then do a transfer transaction to transfer a Kitty from one user account to another. Other things to keep in mind Resources must be created using the “create” keyword. At the end of a function with resources, the resources should either be moved or destroyed. Accessing a field or a function of a resource does not destroy it. When a resource is moved, the constant or variable currently holding the resource becomes invalid. To make a resource type explicit, the prefix @ must be used in type annotations. Comparison and Benefits Resource-oriented programming versus ledger-based systems A common comparison of the ownership structure in resource-oriented programming is with ledger-based ownership. In the ledger model, like in ERC721 smart contracts, every time you have to update ownership, you need to update the mapping of the ID in a shared ledger. In resource-oriented programming, resources are stored within the account of the owner itself, so transferring a digital asset only means moving the resource from the first party to the second. This does not require updating any ledgers. Resource-oriented programming is more suitable for blockchain use cases like digital assets than the traditional ledger system. Benefits of resource-oriented programming There are several benefits that resource-oriented programming brings to the table. Let’s look at some of them below. Makes capability-based security possible Resource types provide the foundation on which capability-based security can be established. Capabilities are one of the best methods to create highly secure blockchain authorization systems. This brings the utmost security to the Flow blockchain. Eliminates reentrancy attacks Reentrancy attacks are one of the most severe smart contract vulnerabilities often exploited by hackers. In a reentrancy attack, a hacker calls the withdraw function on a smart contract recursively. This way, they are able to drain the entire funds of a smart contract. Since methods within a resource cannot be accessed by anyone but the owner, there is no possibility of a reentrancy attack. Better pricing and cost management In Ethereum, the CryptoKitties contract has 2 million digital assets collectively taking up more than 100 MB of space, living rent-free on the Ethereum blockchain. In an ideal world, it should be possible to charge the owners of Kitties based on how much of this data belongs to them on-chain. In Flow, since the resource is directly stored in the account of the owner, it is clear who needs to pay the cost for that data. Conclusion Resource-oriented programming is a new and innovative programming paradigm that has been brought to the blockchain world by the Flow blockchain. It makes resource management very efficient, easy, and secure. It also helps provide a better cost-sharing model for running blockchain infrastructure. You can refer to the on Resources to learn more. I also recommend that you get your hands dirty by going through and this . official docs page Flow Docs tutorial on Resources

The Power of Resource-Oriented Programming in Flow/Cadence: A Deep Dive

Many alternative blockchains that have emerged recently are classified as “EVM” chains, meaning they operate exactly like but have a different execution layer. This helps the cross-compatibility of smart contracts across chains, but it doesn’t solve some of the crucial problems embedded in the EVM system. In particular, it hasn’t improved how user accounts are handled and protected. Ethereum , a layer-1 blockchain, is trying to change that pattern with its account model. In this article, we’ll look in detail at that new account model, how it works, and how it might be able to solve some of the most difficult UX problems in blockchain. Flow How do Accounts on Ethereum Work? One of the best ways to understand how the Flow account model excels is to compare it to Ethereum. There are two types of accounts on Ethereum: externally owned accounts (EOA), which are your typical consumer wallets, and then smart contract accounts. EOAs have a public and private key pair, where the public key is derived from the private key and works as an address for the account, and the private key signs transactions on the blockchain. They can hold a balance and interact with other accounts, primarily smart contract accounts. These smart contract accounts are compiled byte code that runs on the Ethereum Virtual Machine. What’s really interesting is that any data created by the smart contract, such as tokens or NFTs, is stored in that smart contract. Instead of an EOA truly owning the token, the smart contract simply says who owns what and how much. Ethereum’s potential security gaps Not only is true digital ownership conceded, but smart contracts on Ethereum are hard to read and audit for security. A great number of scams and “rug pulls” have occurred on EVM chains because of this power imbalance. Such a scam would usually look like this: A website, which looks very similar to a popular NFT project, touts a new collection at a reasonable mint price. People visit the site, connect their wallet, and when they click that mint button, they will likely get a screen with a bunch of blockchain byte code that tells them nothing about what will happen if they sign. It could just mint an NFT, or it could completely deplete their wallet. Without the ability to read the transactions well, wallets are not able to give the end user much info as to what will happen when they sign. (Note that Flow, covered in more detail below, has a better transaction format that allows wallets to clearly tell the end user what will happen when they sign, giving more balance and control to the user.) How do Accounts on Flow work? The Flow account model combines the concepts of the EOA and smart contract accounts from Ethereum into a single standard. In this model, the account and the public keys are decoupled. As stated earlier, Ethereum accounts only have a public and private key, and they are tied to the account itself. This is important as it enables better control and reduces potential mistakes made by the end user, ultimately helping protect their assets. With the , you can have a single account with multiple public and private keys. Having multiple keys is a huge advantage because you can revoke or rotate keys that might be compromised, again giving the user better control and security. Not only that, but these keys are weighted keys, giving them the ability to do more complex transactions such as multiple signatures.These signatures are used frequently in blockchain to let multiple users sign one transaction, similar to how you might need two keys to open a bank vault. In the EVM model this has to be built out manually, but with Flow it is readily available. Flow account model Since there can be multiple keys for one account, the way Flow creates addresses is also unique. Unlike Ethereum—where addresses are derived from the public key—Flow account addresses are created with an internal on-chain checksum at the protocol level. This ensures addresses are unique. In addition, Flow gives developers and users the option of different signature and hash algorithm curves, such as secp256k1 (used primarily by Bitcoin and other cryptocurrencies) or the more flexible P-256 (which is adopted by most cell phones and computers). These options provide better flexibility and compatibility with other protocols and ultimately give users top-notch security, all on devices they already use daily. And since encryption and cryptography are always evolving, it’s critical and necessary to adopt the latest standards. Storage with Flow Another thing unique to Flow’s account model is its storage capabilities. On Ethereum, only smart contract accounts have the ability to store data and thus truly own assets. You can think of it like leasing a car: if you lease one, you do get to drive it and park it at your house, but it's not truly yours. There’s a contract saying you own the car under certain terms, and the ultimate power is in that contract— and its terms may not always favor the lessee. On the other hand, Flow accounts allow for asset storage and for accounts to deploy their own smart contracts. The account storage used is calculated by the byte size of data currently stored in the account, and it is directly tied to the balance of Flow tokens on the account. True digital ownership: buy, don’t lease This is truly special as it gives users the ability to truly own the digital items they purchase, rather than a smart contract putting their name on it. Flow manages this storage by the number of Flow tokens the account has, including a minimum storage feed of 0.001 $FLOW, which equates to 100Kb of data. (This is to make sure it can handle any incoming assets.) If, for any reason, the account attempts a transaction that would exceed its storage capacity, then the transaction will fail. In the Flow account model, that car is in your garage with no contracts tied to it! Paid in full. Conclusion Flow is trying to diverge from the normal EVM path. In the Ethereum world, there are many cases of users losing funds partly due to the account model on EVM chains, which makes it difficult for users to read and interpret what will happen when they press a button on a website. Flow aims to empower users to own their digital assets and ensure funds will only leave their accounts with their permission. Flow also gives developers flexibility, making things like multi-signature weighted keys native to the platform, as well as multiple signature and hashing algorithms to choose from for the best compatibility among devices and networks. It’s early, but these kinds of features are needed in Web3 UX and could be a potential game-changer.

Giving Power Back to Your Users with Flow’s Account Model

Blockchain has the potential to revolutionize the way we interact with the digital world. It promises security, transparency, and decentralization. However, for most people, getting started with blockchain can be confusing and intimidating. The need to manage private keys and wallets can be a significant hurdle. To , developers have been exploring ways to simplify the process, and one exciting concept is . In this article, we’ll look at what abstraction is and how it creates a better wallet experience. Later, we’ll take a detailed look at how it is implemented on , a blockchain-focused on mainstream web3 adoption and used by companies such as the NBA, NFT, Ticketmaster, and Mattel. make blockchain more accessible abstraction web3 Flow What is abstraction? In the realm of computer science and software development, abstraction is a fundamental concept. Abstraction simplifies a system by removing certain characteristics to reduce complexity and enhance efficiency. For most blockchain users, dealing with private keys and wallets can be intimidating and inconvenient. Abstraction in blockchain aims to address this issue. There are two primary ways to manage keys and assets in the blockchain: user custody and application custody. User Custody This is considered the safest and most ideal version of blockchain management. With user custody, you hold your own keys on a device like your computer or phone. A special software called a "wallet" helps manage access to your keys. When you use a blockchain application, it asks your wallet for permission to do things like send money, and you get to approve or deny these requests. User custody gives you full control and security over your assets. Application Custody On the other hand, application custody is an approach in blockchain where the responsibility of managing private keys and wallet software is shifted from the user to the application or service provider. Let’s see how it works and why it's valuable: With application custody, the user onboarding process is designed to be extremely user-friendly, similar to how people sign up for traditional online services. Users are not required to install any wallet software or deal with the complexities of managing private keys. They can create an account with the blockchain application just as they would with any other web2 service, using a username and password or other familiar credentials like their Google or Facebook login. User-Friendly Onboarding: In an application custody model, users don't have to worry about onerous wallet management, such as securely storing private keys or making backups. This simplification is especially attractive to users who are new to blockchain technology and may find the concept of wallets and private keys confusing. No Wallet Management: Application custody also enables blockchain applications to accept traditional payment methods, such as credit cards for web-based applications or native in-app purchases for mobile apps. This means that users can pay for blockchain-based services using methods they are already familiar with, making the payment process seamless and comfortable. Traditional Payment Methods: Another advantage of application custody is that applications can manage the assets within the user's account directly, all without needing to request user consent for every action. For example, if a user purchases an item within a mobile game using in-app purchases, they don't have to repeatedly approve each transaction through their wallet. This streamlines the consent process and feels more like the traditional web2 user experience. Reduced User Consent: Application custody isn’t just convenient; it also prioritizes a user-friendly onboarding experience by handling key management and wallet complexities on behalf of the user. However, it limits the portability of assets outside of the application, which is where the concept of account abstraction (specifically account delegation) comes into play. Abstraction bridges the portability gap and offers users more control and flexibility over their . blockchain assets The Solution - Connecting both worlds with abstraction To solve this issue and to create a balance between user custody and application custody, developers are turning to something called "account abstraction," specifically, "account delegation." Account delegation refers to a dynamic in which any account that has a valid capability to another account object in the storage can access it. This feature allows one blockchain account to delegate control to another. The account that delegates (the "child" account) still uses cryptographic keys, but the owner of the other account (the "parent" account) gains access to its assets. Importantly, the child account must give permission for this access, and it can take it back at any time. This connection between accounts forms a hybrid custody model that combines the benefits of both user and application custody. How it works Here's how it works in simple terms: New users, who might find the idea of managing keys intimidating, can sign up for an account without dealing with wallets. It's similar to signing up for any other online service. Easy Start: As users become more familiar with blockchain and gain confidence in managing their keys, they can delegate control of their app-custody account to their self-custody account. Growing Confidence: With their own keys on their own devices, users can access all their assets in both accounts. They keep control while still letting the application manage assets in the child account, reducing the need for constant interactions with wallets. Full Control: Because this delegation relationship is tracked on the blockchain, the application can recognize it and access the assets in the parent account when necessary. This makes it easy for users to move assets between accounts for seamless access. Interoperability: Deep dive into walletless building Before moving forward, it's important to understand the concept of account linking, a unique Flow concept that enables the sharing of ownership over accounts. (the smart contract programming language for Flow) provides two ways to access Flow accounts: Cadence This gives you access to public account info like address, balance, and storage, but you can't make changes. PublicAccount: With AuthAccount, you get the same access plus the ability to make changes, like adding/removing keys and managing contracts. AuthAccount: With Cadence, you can create permissions to share access to account storage. This means if an account has valid permission to access another account's storage, it can get in. You can also control what parts of the storage can be accessed with these permissions. Account linking is doable by adding these permissions to the AuthAccount object. Just like storage permissions allow access to data stored in an account, AuthAccount permissions enable access to the AuthAccount itself. When we talk about "account linking," it's like a parent account sharing a special access card (AuthAccount capability) with another account, making it their child account. This happens in two simple steps on Flow: The child account creates and shares the AuthAccount capability with the parent account. Implementation in code: Create Capability transaction {
    prepare(signer: AuthAccount) {
        let capability = signer.linkAccount(/private/accountCapA)!
        signer.inbox.publish(capability, name: "accountCapA", recipient: 0x1)
    }
} The parent account can then use this capability to access the child's account easily. Implementation in code: Claim Capability transaction {
    prepare(signer: AuthAccount) {
Let capability = signer.inbox.claim<&AuthAccount>("accountCapB", provider: 0x2)!
        let accountRef = capability.borrow()!
    }} Why is account linking useful? Account linking was created to help users easily join your Flow-based app without needing a wallet first. This makes it simple for everyone to use Flow apps without technical issues or the need to install a wallet. You can enjoy apps right away and also have the option to own your data later on. With account linking, users can connect multiple app accounts together. You don't need to worry about the complexities of accessing these accounts because it's all managed through one main account. The best part? Assets can move freely between these accounts without any extra transactions. Your app account can now interact with the broader Flow ecosystem seamlessly. With this feature, users can have full control over their digital items in their in-app account. This means they truly own these items, not just within the app but also outside it. They can easily view their inventory using their parent account and even use these items in other apps, like a marketplace or a game. The best part is they can do all this without the hassle of transferring items between accounts, making it super convenient to use multiple apps at once. Conclusion Blockchain development is evolving to make it easier for everyone to get involved. Abstraction, through account delegation, is a key part of this evolution. It combines the safety of user custody and the convenience of application custody, allowing users to transition smoothly from beginners to experts in . As blockchain technology continues to grow, these innovative ideas will help make it more accessible to everyone. the blockchain world Have a really great day! Also published . here

Simplifying Blockchain: How Abstraction is Revolutionizing the Web3 Wallet Experience on Flow

Welcome to the final step in creating your Collectibles portal! of this short series focused on building the collections portal. In this part, we'll focus on building the front end—the last piece of the puzzle. Here's what we'll achieve: Part one Connect with Flow Wallet: You'll be able to link your Flow Wallet. Create NFTs (Mint): You can make your very own by confirming the transaction. NFTs View NFTs: You'll be able to see your NFTs by asking the blockchain. We will work with React.js and an existing smart contract on Flow's testnet. This smart contract is the same Collectibles contract we crafted in part 1. Here are the steps we will follow to get there: : Setting things up and getting ready to go. Installation : Getting everything in order for a smooth operation. Configuration : Making sure you're securely connected. Authentication : Asking the blockchain for information. Querying the Flow Blockchain : Preparing your account for action. Setting up the Account : Modifying the blockchain as needed. Mutating the Flow Blockchain : Keeping track of your code. Final Step Are you ready to dive into creating your Collectibles Portal's front end? Let's get started! 1. Installation First, we need to create a React app using a tool called Yarn. To do this, open your terminal and type: yarn create react-app web After pressing Enter, your computer will begin creating a new React app inside your project. When it's done, you can open your new app. This is what your React app looks like. 2. Configuration We'll use the to manage wallet connections, run scripts, and send transactions in our application. Flow Client Library (FCL) To get started, let's install FCL for our app by running the following command: npm install @onflow/fcl --save After installing FCL, we need to configure it. Here's what you need to do: Create a file named config.js in the src folder. In this file, set up the configuration for the FCL, such as specifying the Access Node and wallet discovery endpoint. This helps you choose between using a testnet or a local emulator. Add the following code to the config.js file: import { config } from "@onflow/fcl";

config({
  "accessNode.api": "https://rest-testnet.onflow.org", // Mainnet: "https://rest-mainnet.onflow.org"
  "discovery.wallet": "https://fcl-discovery.onflow.org/testnet/authn" // Mainnet: "https://fcl-discovery.onflow.org/authn"
}) Now, you're all set up to use the FCL in your app. 3. Authentication To verify a user's identity in an app, you can use several functions. For logging in use . fcl.logIn() For signing up use . fcl.signUp() For logging out call . fcl.unauthenticate() After logging in, an object named is set up. This object allows you to watch for changes in user data, perform transaction signings, and more. Let's add several buttons for sign up/login and also subscribe to changes on the . When the user is updated (which will happen after authentication), we'll set the user state in our component to reflect this. To demonstrate user-authenticated sessions, we'll conditionally render a component based on whether the user is or is not logged in. Your code should look like this: fcl.currentUser currentUser import React from "react";
import './styles/App.css';
import "./config";
import * as fcl from "@onflow/fcl";

const App = () => {

  const [user, setUser] = useState({loggedIn: null})

  useEffect(() => fcl.currentUser.subscribe(setUser), [])

  const AuthedState = () => {
    return (
      <div>
        <div className="sub-text">Wallet Address: {user?.addr ?? "No Address"}</div>
        <button className="cta-button connect-wallet-button" onClick={fcl.unauthenticate}>
          Log Out
        </button>
      </div>
    )
  }

const UnauthenticatedState = () => {
    return (
        <button className="cta-button connect-wallet-button" onClick={fcl.logIn}>
          Log In
        </button>
    )
  }
  return (
    <div className="App">
      <div className="container">
        <div className="header-container">
          <p className="header gradient-text">Flow Collectibles Portal</p>
          <p className="sub-text">Upload your favorite collectibles to the Flow Blockchain</p>
          {user.loggedIn ? <AuthedState /> : <UnauthenticatedState />}
        </div>
      </div>
    </div>
  );
};

export default App; Now, you can either log in or sign up as a user and then log out. When you log in or sign up, a small window will pop up. In that window, you can pick a wallet provider. For this instance, let's pick the Blocto wallet to make an account. After you successfully prove it's you, you will see your wallet address on the screen like this: 4. Querying the Flow Blockchain When you're , a key task is to retrieve data from the blockchain and the smart contracts it holds. Let's understand how we can query a contract to find out about a specific NFT. Here's a simplified breakdown of the steps involved: building a dapp Import Contracts: First, you need to import the relevant contracts used in your dapp. In this example, we're interested in querying the NFTs, so we're importing the NonFungibleToken and Collectibles contracts. Use FCL: You create a function called queryNFT, which is asynchronous. Inside this function, you use the fcl.query function to query the blockchain. Set the result of the script to the app state in React so we can display the NFT in our browser. Display: Display "No NFT" if nothing was found. Take a look at the new code. We'll explain each new piece as we go. const [user, setUser] = useState({loggedIn: null})
const [nft, setNFT] = useState() //NEW

useEffect(() => fcl.currentUser.subscribe(setUser), [])

  // NEW
  const queryNFT = async () => {
    const nft = await fcl.query({
      cadence: `
        import NonFungibleToken from 0x631e88ae7f1d7c20
        import Collectibles from 0x490b5c865c43d0fd

        pub fun main(user: Address, id: UInt64): &NonFungibleToken.NFT? {
          let collectionCap= getAccount(user).capabilities
                      .get<&{Collectibles.CollectionPublic}>(/public/NFTCollection) 
                      ?? panic("This public capability does not exist.")

          let collectionRef = collectionCap.borrow()!

          return collectionRef.borrowNFT(id: id)
        }
      `,
      args: (arg, t) => [arg(user.addr, t.Address)]
    })

    setNFT(nft ?? 'No NFT')
  }

const AuthedState = () => {
    return (
      <div>
        <div className="sub-text">Wallet Address: {user?.addr ?? "No Address"}</div>
        <div className="sub-text">NFT: {nft ?? "--"}</div>
       <button className="cta-button" onClick={queryNFT}>View NFT</button>
       <button className="cta-button connect-wallet-button" onClick={fcl.unauthenticate}>
          Log Out
        </button>
      </div>
    )
  } A few things happened. In our AuthedState component, we added a button to send a query to view the NFT and a div to display the result above it. You can see the corresponding useState initialization at the top of the component. We also built out the actual query inside of the queryNFT method. Let's take a look at it more closely. await fcl.query({
      cadence: `
        import NonFungibleToken from 0x631e88ae7f1d7c20
        import Collectibles from 0x490b5c865c43d0fd

        pub fun main(user: Address, id: UInt64): &NonFungibleToken.NFT? {
          let collectionCap= getAccount(user).capabilities
                      .get<&{Collectibles.CollectionPublic}>(/public/NFTCollection) 
                      ?? panic("This public capability does not exist.")

          let collectionRef = collectionCap.borrow()!

          return collectionRef.borrowNFT(id: id)
        }
      `,
      args: (arg, t) => [arg(user.addr, t.Address)]
    }) Inside the query, you'll see we set two things: cadence and args. Remember that the Cadence code is specific to Flow's smart contract language, and you don't need to dive too deep into it unless you're working on writing more complex smart contracts. The key takeaway is that you're querying the blockchain to get NFT information based on the user's account address and the NFT ID. When you click the "View NFT" button, you'll see the NFT details, or if the NFT doesn't exist, it will display "No NFT". 5. Setting up the Account We use a process called "collection initialization” to set up a Collection resource in the user’s account. (We covered what a resource is in Part 1. You can review that here.) To make this happen, we’ll add a new function called "initAccount.” We'll use a code that asks, "Hey, does this account already have a Collection? If not, let's create one." We use something called a "transaction" to do this. Think of a transaction as a special task we want the system to do for us. Now, let's talk about how we write this code. Instead of saying "query," we use the word "mutate" for transactions. Since doing this task has a cost, we need to provide some information to Flow. We tell Flow who is suggesting the task, who is approving it, who is paying for it, and how much they're willing to pay. These parts are called "proposer," "authorizer," "payer," and "limit." Let's take a look at what the function to set up an account looks like. const initAccount = async () => {
  const transactionId = await fcl.mutate({
    cadence: `
    import Collectibles from 0x490b5c865c43d0fd

    transaction {
    prepare(signer: AuthAccount) {
        if signer.borrow<&Collectibles.Collection>(from: Collectibles.CollectionStoragePath) == nil {
            let collection <- Collectibles.createEmptyCollection()
            signer.save(<-collection, to: Collectibles.CollectionStoragePath)
            let cap = signer.capabilities.storage.issue<&{Collectibles.CollectionPublic}>(Collectibles.CollectionStoragePath)
            signer.capabilities.publish( cap, at: Collectibles.CollectionPublicPath)
        }
    }
    `,
    payer: fcl.authz,
    proposer: fcl.authz,
    authorizations: [fcl.authz],
    limit: 50
  })

  const transaction = await fcl.tx(transactionId).onceSealed()
  console.log(transaction)
} You can see the new fields we talked about. You'll also notice , which is shorthand for "use the current user to authorize this transaction.” You could also write it as . fcl.authz fcl.currentUser.authorization For this example, we'll keep it simple with the user being each of these roles. You'll also notice we are awaiting a response with our transaction data by using the syntax . This will return when the blockchain has sealed the transaction and it's complete in processing and verifying it. Now, your App.js file should look like this. (we also added a button for calling the function in the ): fcl.tx(transactionId).onceSealed() initAccount AuthedState const App = () => {

  const [user, setUser] = useState({loggedIn: null})
  const [nft, setNFT] = useState() //NEW
  const [txnStatus, setTxnStatus] = useState(null)

  useEffect(() => fcl.currentUser.subscribe(setUser), [])

  // NEW
  const queryNFT = async () => {
    const nft = await fcl.query({
      cadence: `
        import NonFungibleToken from 0x631e88ae7f1d7c20
        import Collectibles from 0x490b5c865c43d0fd

        pub fun main(user: Address, id: UInt64): &NonFungibleToken.NFT? {
          let collectionCap= getAccount(user).capabilities
                      .get<&{Collectibles.CollectionPublic}>(/public/NFTCollection) 
                      ?? panic("This public capability does not exist.")

          let collectionRef = collectionCap.borrow()!

          return collectionRef.borrowNFT(id: id)
        }
      `,
      args: (arg, t) => [arg(user.addr, t.Address)]
    })

    setNFT(nft ?? 'No NFT')
  }

  // NEW
  const initAccount = async () => {
  const transactionId = await fcl.mutate({
    cadence: `
    import Collectibles from 0x490b5c865c43d0fd

    transaction {
    prepare(signer: AuthAccount) {
        if signer.borrow<&Collectibles.Collection>(from: Collectibles.CollectionStoragePath) == nil {
            let collection <- Collectibles.createEmptyCollection()
            signer.save(<-collection, to: Collectibles.CollectionStoragePath)
            let cap = signer.capabilities.storage.issue<&{Collectibles.CollectionPublic}>(Collectibles.CollectionStoragePath)
            signer.capabilities.publish( cap, at: Collectibles.CollectionPublicPath)
        }
    }
    `,
    payer: fcl.authz,
    proposer: fcl.authz,
    authorizations: [fcl.authz],
    limit: 50
  })

  const transaction = await fcl.tx(transactionId).onceSealed()
  console.log(transaction)
}

  const mintNFT = async () => {
  const transactionId = await fcl.mutate({
    cadence: `
      import Profile from 0xProfile

      transaction(name:String, image:String){
        let receiverCollectionRef: &{NonFungibleToken.CollectionPublic}
        prepare(signer:AuthAccount){
          self.receiverCollectionRef = signer.borrow<&Collectibles.Collection>(from: Collectibles.CollectionStoragePath)
              ?? panic("could not borrow Collection reference")
        }
        execute{
          let nft <- Collectibles.mintNFT(name:name, image:image)
          self.receiverCollectionRef.deposit(token: <-nft)
        }
      }
    `,
    args: (arg, t) => [arg("Pikachu", t.String),arg("https://cdn.pixabay.com/photo/2020/08/29/16/08/pikachu-5527377_640.jpg",t.String)],
    payer: fcl.authz,
    proposer: fcl.authz,
    authorizations: [fcl.authz],
    limit: 50
  })

  fcl.tx(transactionId).subscribe(res => setTxnStatus(res.status))
}


    const AuthedState = () => {
    return (
      <div>
        <div className="sub-text">Wallet Address: {user?.addr ?? "No Address"}</div>
        <div className="sub-text">NFT: {nft ?? "--"}</div>
        <div className="sub-text">Transaction Status: {txnStatus ?? "--"}</div>
        <button className="cta-button" onClick={queryNFT}>View NFT</button>
        {/*NEW*/}
        <button className="cta-button" onClick={initAccount}>Create Collection</button>
        <button className="cta-button" onClick={mintNFT}>Mint</button>
        <button className="cta-button connect-wallet-button" onClick={fcl.unauthenticate}>
          Log Out
        </button>
      </div>
    )
  }


  const UnauthenticatedState = () => {
    return (
        <button className="cta-button connect-wallet-button" onClick={fcl.logIn}>
          Log In
        </button>
    )
  }

  return (
    <div className="App">
      <div className="container">
        <div className="header-container">
          <p className="header gradient-text">Flow Collectibles Portal</p>
          <p className="sub-text">Upload your favorite collectibles to the Flow Blockchain</p>
          {user.loggedIn ? <AuthedState /> : <UnauthenticatedState />}
        </div>
      </div>
    </div>
  );
};

export default App; Click the "Init Account" button. This will prompt your wallet to ask for permission to complete a transaction. Once you give permission, you'll notice a message about the transaction in the console. (Make sure the console is open.) This might take a short while. Once the message shows the result of the transaction, you can use the transactionId to find out more details about the transaction using a . block explorer 6. Mutating the Flow Blockchain After initializing the account and setting up the collection resource into it, we now and store it in the collection. To do this, we will write another transaction that allows us to mint the NFT. Everything else looks the same in the following code except for one thing: We'll subscribe to the status changes instead of waiting for them to be sealed after the mutate function returns. It looks like this: mint the NFT const executeTransaction = async () => {
const transactionId = await fcl.mutate({
    cadence: `
      import NonFungibleToken from 0x631e88ae7f1d7c20
      import Collectibles from 0x490b5c865c43d0fd

      transaction(name:String, image:String){
        let receiverCollectionRef: &{NonFungibleToken.CollectionPublic}
        prepare(signer:AuthAccount){
          self.receiverCollectionRef = signer.borrow<&Collectibles.Collection>(from: Collectibles.CollectionStoragePath)
              ?? panic("could not borrow Collection reference")
        }
        execute{
          let nft <- Collectibles.mintNFT(name:name, image:image)
          self.receiverCollectionRef.deposit(token: <-nft)
        }
      }
    `,
    args: (arg, t) => [arg("Pikachu", t.String),arg("https://cdn.pixabay.com/photo/2020/08/29/16/08/pikachu-5527377_640.jpg",t.String)],
    payer: fcl.authz,
    proposer: fcl.authz,
    authorizations: [fcl.authz],
    limit: 50
  })

  fcl.tx(transactionId).subscribe(res => setTransactionStatus(res.status))
} Here you can see our two arguments which are "Pikachu” and image URL “ ”. At the bottom, we've called the subscribe method instead of onceSealed. Let's see how that works inside our whole app.js file. Let’s also set the status to our React component's state so we can see what state we're in on screen. https://cdn.pixabay.com/photo/2020/08/29/16/08/pikachu-5527377_640.jpg Conclusion Well done! You've finished part 2 of the Collectibles portal project. In summary, we focused on building the front end of our Collectibles portal. We did this by: Creating an app with React.js Connecting with Flow Wallet Creating our very own NFTs for minting Viewing NFTs by asking the blockchain Now you have a better understanding. Keep up the fantastic effort! Have a really great day! Also published . here

Build an NFT Website Using The Flow Blockchain and Cadence [Part 2]

Build an NFT Website Using The Flow Blockchain and Cadence [Part 1]

If you’re a developer working on a web3 app, you know that onboarding mainstream users into web3 is difficult. Even with the promise of truly owning your data, making near-free worldwide payments, and using a censorship-free system, the current process of creating and using a digital wallet is just too hard. Fortunately, there’s a better way. promises to streamline the process, making user onboarding seamless and simple. —a decentralized, public, layer-one blockchain designed for building web3 experiences for mainstream users—has used account abstraction to combine a model with to create an onboarding that is easy, simple, and as straightforward as traditional apps. Account abstraction Flow hybrid custody walletless onboarding Let's dive into the details to see how Hybrid Custody and Walletless Onboarding work together: the architecture, the code, and what we can expect moving forward. Why web3 onboarding is so difficult Digital wallets bring all the benefits of web3, including the assurance that no one can control your assets. There are no middlemen such as banks taking a percentage of your money, or third parties dictating what you can do. However, because most wallets are “self custody” (meaning only you have access), you—and only you—are in charge of your keys. There is no customer support if you make a mistake. This means you must store your keys safely. Don’t store them in clear text on your computer where they can be hacked. And don’t write them down where someone can read them. And don’t lose them, because there is no reset password in web3, so you’ll lose . You can see the issues. everything In addition to the challenges of self custody, you also need to understand tokens and payments. How do you pay for your transactions? What tokens do you need? How do you move from fiat to tokens? How do you transfer the tokens once you have them? Oh, you made a typo when you sent your tokens? Sorry, they’re lost forever. Again, you can see how difficult this all is. With all these obstacles, it’s easy to see why many people don’t make it past step one of signing up for your app. Custodial wallets: great UX, lacking ownership Developers tried to solve this issue with . These wallets manage the keys for you and have many benefits. custodial wallets Signing up is easy. You can use an email and password, as you would for a traditional service, and the wallet provider takes care of the rest. If you lose your login credentials, your keys are still accessible on the provider's servers – you can simply request a password reset. Since the wallet software runs on their servers, providers can even pay your fees. You don’t have to understand tokens, funding, and transfers. transaction But as the saying in web3 goes: “Not your keys, not your coins!” While custodial wallets solved many onboarding issues, the wallet providers, in the end, owned the keys. We’re right back to the problems we wanted to get away from: a centralized entity that can prevent you from using your tokens, can close your account at a whim, or can shut down completely, taking your funds with them. Wouldn’t it be nice if you could have the best of both worlds? Account abstraction to the rescue! solves one of the fundamental issues of blockchain networks: the distinction between externally owned accounts and contract accounts. Account abstraction An (EOA) is an account controlled by the user with a private key. These are the traditional web3 wallets that we talked about above. An EOA has a public address and initiates transactions (such as sending tokens) with the blockchain. externally owned account A (which is also just a smart contract) is a program deployed on-chain and executed by the network nodes. Contract accounts don’t initiate transactions. Instead they respond to a transaction with an action of their own. They have no private key—they are controlled by their code. This type of account could be said to have . contract account app-custody Account abstraction combines app-custody and self-custody into a new user experience (UX), giving users the benefits of both: control of their wallets, while abstracting away the wallet (and blockchain) altogether. On Flow, account abstraction is the basis for Walletless Onboarding using Hybrid Custody. Hybrid Custody gives you the best of both worlds allows developers to create an onboarding experience for users that is nearly seamless. Walletless Onboarding The walletless user journey (from flow.com) The hybrid custody model uses account abstraction to allow —where a child account delegates control to a parent account through a , essentially allowing one account to control another. account delegation Capability Now, the self-custody account can be a parent account, giving permissions to the app account, which is now a child account. With this setup, the accounts work together, and your app can work like this: Your app creates the wallets for the users. There is no barrier to entry here—no key management, no signing transactions, no understanding of blockchain. Users can use your app, and buy and sell assets, without knowing or caring about the technical details. Your app can even subsidize transaction fees or let them fund their account with fiat such as USD. And it all happens invisibly to the user. Once the user comes back with their own wallet-managed account, your app can delegate access to the user’s account. Once linked, the user has hybrid custody – their wallet manages their main (now “parent”) account which secondarily maintains access on the app-created (now “child”) account. Since their main account now has access on the app-created account, they can bring app assets anywhere their wallet-managed account goes. They can trade your app’s assets on marketplaces or share them with friends. Yet, at the same time, since the app also has access to the account, it can still facilitate seamless UX that acts on their behalf. With this hybrid custody model, users get to experience your app right away, with minimal barriers and no risk. And later on, if they choose, they can take control of the self-custody account themselves, enjoying all the real ownership and self-sovereignty it brings. Technical details of hybrid custody and account abstraction Account Creation How does all this work? On and many other blockchain networks, an EOA is created from a public key. The key is hashed, and the first 160 bits of this hash become the address of the account controlled by that key. This makes account creation independent from the network but irrevocably ties an account to that key. Ethereum Flow uses a particular on-chain function to create account addresses. You can then add any number of keys to a Flow account, adding and removing access based on the custodian of each key. This means a transaction is required to create a new address—so you can’t create accounts offline—but it also makes Flow account ownership much more flexible. You can see , but let’s check out the crucial parts here: a full account creation example on GitHub FromPrivateKey(userPrivateKey).
  SetHashAlgo(crypto.SHA3_256).
  SetWeight(flow.AccountKeyWeightThreshold) examples.ServiceAccount(flowClient) []*flow.AccountKey{userPublicKey}, 
  nil, 
  serviceAccountAddress
)


createAccountTx.SetProposalKey(
  serviceAccountAddress,
  serviceAccountKey.Index,
  serviceAccountKey.SequenceNumber
)


createAccountTx.SetReferenceBlockID(
  examples.GetReferenceBlockId(flowClient)
)


createAccountTx.SetPayer(serviceAccountAddress)

_ = createAccountTx.SignEnvelope(
  serviceAccountAddress,
  serviceAccountKey.Index,
  serviceSigner
)
_ = flowClient.SendTransaction(ctx, *createAccountTx) userPrivateKey := examples.RandomPrivateKey() userPublicKey := flow.NewAccountKey(). serviceAccountAddress, serviceAccountKey, serviceSigner := createAccountTx, _ := templates.CreateAccount( First, the user creates a key pair. Pretty basic stuff. Because on Flow, you create accounts by sending an account creation transaction, we need an existing account to send this transaction. This housekeeping is the job of the . ServiceAccount The receives the user’s public key to control the new account later, but the , which signs and pays for the transaction, handles the rest. In the case of your app, you would own this service account so you could sign account creation transactions on behalf of your user, also funding the account’s creation. createAccountTx ServiceAccount Hybrid Custody Let’s get back to the hybrid custody model. Your app can create app accounts for your users and link them to a public key that your app controls. The app can then handle your user's transactions and assets and even sponsor their transaction fees, just like any custodial account would do. Later, when a user decides to dive deeper into the web3 ecosystem and get their own wallet, you can create and save a link to the app-custodied account’s , and delegate control to the user’s wallet-managed account. AuthAccount Capability You can see an example of this in the where a multisig transaction is executed by the app to link a user's account to a walletless onboarding, dapp-custodied account to the signing user’s wallet-managed account. walletless arcade example Summary It’s worth driving the point home that delegating access on the app-created account is done via a linked Capability on the account which is then provided to the user. This mechanism for account delegation is completely new to blockchain accounts, and is only possible because of the account abstraction that’s been native to Flow for years now. This language API account linking feature is a huge advantage to accounts on Flow, in addition to many other features – m-of-n multisig, re-keying accounts, etc. – which are only now beginning to be realized on other chains with their nascent, non-native account abstraction implementations. Account abstraction is a powerful feature. On , it enables a hybrid custody model that allows users to enjoy the benefits of a custodial account when they sign up, while enabling them to take the account into self-custody at any time. It’s a new – and vastly improved – user experience that hopefully brings millions more users into web3. Flow Also published here .

Web3 Onboarding is Terrible — Make it Better With Account Abstraction and Flow

Throughout this article series, we’ve its , and some of the most , all while comparing and contrasting to Ethereum. introduced you to the Flow blockchain, smart contract language Cadence essential tools developers should know In this article, we will talk about best practices and patterns that should be followed when using the Cadence language and developing solutions on the Flow network, as well as patterns to avoid. Best practices Use Flow Test Network and Flow Emulator One of the most important steps in developing on any blockchain is testing your projects in a simulated environment. Flow blockchain is no different. For this purpose, the and are both crucial components to include in your development process. Not only do they allow you to understand how your dapp will perform, but they will also help you catch any critical bugs before deploying to mainnet. Flow testnet Flow Emulator Use Standard Contracts Two of the most common use cases for any blockchain are digital currencies and providing proof of digital ownership through NFTs. Instead of trying to rewrite the necessary contracts from scratch, Flow developers should always import the official core contracts to ensure user safety and consistency with the rest of the network. There are currently three standard contracts you should use: — Used to create new tokens Fungible Token — Used to create NFTs Non-Fungible Token — Used as a metadata pattern for NFTs Metadata Views These contracts are essentially interfaces that force whoever is implementing them to add their variable and method declarations, enabling them to be interoperable with other smart contracts in the Flow ecosystem. They already exist on both testnet and mainnet networks, so be sure to import from the official addresses linked above when implementing them in your contract. You can find other core contracts . in the Flow documentation Create Tests for Your Smart Contracts, Transactions, and Scripts The is crucial for testing deployment scenarios for your contracts. However, it’s important to note that you’ll need the running in the background for full functionality. With these, you can test creating new accounts, sending transactions, running queries, executing scripts, and more. Additionally, it integrates with the Flow Emulator so you can create, run, and stop emulator instances. Flow JavaScript Testing Framework Flow CLI Add Your Contract to the Flow NFT Catalog The exists as a database to store NFT contracts and metadata. By uploading your contract, your NFTs become interoperable with the rest of the Flow ecosystem, and other developers can easily support your collection in their marketplaces or other dapps. Flow NFT Catalog You can by completing a simple four-step process. add your contract to the catalog Be Specific With Types Cadence is a and typed language that allows the developer to specify which types contain or return variables, interfaces, and functions. Therefore, you should be as specific as possible when making declarations; use generic types only in necessary situations. Not doing so can result in clumsy errors. strong statically Access Control Whenever possible, you should be deliberate with access control. Luckily, on the Flow blockchain, a caller cannot access objects in another user’s account storage without a reference to it. This is called reference-based security, and it means that nothing is truly public by default. However, when writing Cadence code, care must be taken when declaring variables, structs, functions, resources, and so on. There are four levels of access control a developer can include in their declarations: — accessible/visible in all scopes pub/access(all) — only accessible in the entire account where it’s defined (other contracts in the same account can access) access(account) — only accessible in the scope of the contract in which it is defined (cannot be accessed outside of the contract) access(contract) — only accessible in current and inner scopes priv/access(self) Avoid using pub/access(all) whenever possible. Check out the Flow documentation for . more information on access control Create StoragePath and PublicPath Constants Inside Your Contract The paths to your contract’s resources are extremely important and must be consistent across all transactions and scripts. To ensure uniformity, you should create constants for both PublicPath and StoragePath. pub contract BestPractices {
	pub let CollectionStoragePath: StoragePath
	pub let CollectionPublicPath: PublicPath

	init(){
		self.CollectionStoragePath = /storage/bestPracticesCollection
		self.CollectionPublicPath = /public/bestPracticesCollection
	}
} When you create a transaction that uses one of these paths, you only need to call its respective variable with the imported contract to reference the required path. //This script checks if a user has the public Collection from BestPractices contract
import BestPractices from 0x...

pub fun main(addr: Address): Bool {
	return getAccount(addr).getLinkTarget(BestPractices.CollectionPublicPath) != nil
} Admin Resource It’s good practice to create an administrative resource that contains specific functions to perform actions under the contract, such as a mint function. This convention ensures that only accounts with that resource or capability can perform administrative functions. pub contract BestPractices {
	pub let CollectionStoragePath: StoragePath
	pub let CollectionPublicPath: PublicPath
	pub let AdminStoragePath: StoragePath

	pub resource AdminResource {
		pub fun mintNFT(){
			//your mint NFT code here! 
		}
	}

	init(){
		self.CollectionStoragePath = /storage/bestPracticesCollection
		self.CollectionPublicPath = /public/bestPracticesCollection
		self.AdminStoragePath = /storage/bestPracticesAdmin
		
		//Create the adminResource and store it inside Contract Deployer account
		let adminResource <- create AdminResource()
		self.account.save(<- adminResource, to: self.AdminStoragePath)
	}
} Create Custom Events Events are values that can be emitted during the execution of your Cadence code. For example, when defining important actions in your contracts, you can emit events to signal their completion or deliver a specific value. As a result, transactions that interact with your smart contracts can receive additional information through these events. pub contract BestPractices {
	pub let CollectionStoragePath: StoragePath
	pub let CollectionPublicPath: PublicPath
	pub let AdminStoragePath: StoragePath

//Create your own events
pub event AdminCreated()
	

	pub resource AdminResource {
		pub fun mintNFT(){
			//your mint NFT code here! 
		}
	}

	init(){
		self.CollectionStoragePath = /storage/bestPracticesCollection
		self.CollectionPublicPath = /public/bestPracticesCollection
		self.AdminStoragePath = /storage/bestPracticesAdmin
		
		//Create the adminResource and store it inside Contract Deployer account
		let adminResource <- create AdminResource()
		self.account.save(<- adminResource, to: self.AdminStoragePath)
	}
} Patterns on Cadence/Flow Blockchain Be Specific With Types in Type Constraints One of the most powerful features of the Cadence language is undoubtedly . Through capabilities, the scope of resource access expands. capabilities An important point when creating a capability is to specify which features of your resource should be available to others. This can be done at the time of link creation using type constraints. In this example, we use the to create a basic functionality where any account that wants to receive an ExampleNFT must have a collection. ExampleNFT contract import NonFungibleToken from 0x...
import ExampleNFT from 0x...

transaction{
	prepare(acct: AuthAccount){
		let collection <- ExampleNFT.createEmptyCollection()
    // Put the new collection in storage
	  acct.save(<-collection, to: ExampleNFT.CollectionStoragePath)
    // Create a public Capability for the collection
    acct.link<&ExampleNFT.Collection{ExampleNFT.CollectionPublic}>(ExampleNFT.CollectionPublicPath, target: ExampleNFT.CollectionStoragePath)
	}
} The & symbol in specifies that we are using a . After the reference symbol, we add the type to which the capability we are creating will have access. At this point, we need to be as specific as possible. &ExampleNFT reference This pattern strengthens security and limits the functionality that the user calling the function of this capability can use. borrow Omitting the type will give you access to all the functions that exist in the reference, including the withdraw function, so that anyone can access the user's collection and steal their NFTs. {ExampleNFT.CollectionPublic} ExampleNFT.Collection Use the Borrow Function To use the resource’s features, you could call the function to remove the resource from the account, use its features, and call the function to save it again. However, this approach is costly and inefficient. Load Save To avoid this, use the function instead. It allows you to use a reference to the resource you are calling. This method makes your transaction much more efficient and cost-effective. borrow Use the check and getLinkTarget Functions When building applications on the Flow blockchain, you will discover the user’s account plays a vital role. Unlike other blockchains, such as Ethereum, Flow stores resources, assets, and more directly in the user’s account rather than as a reference to an address on a public digital ledger. This approach requires the account to have a specific storage location, such as a collection or vault for fungible tokens. However, this also adds complexity. One must be sure that the user either does or does not have the collection in their account. Both the function (which checks whether a capability exists in a given path) and the function (which returns the path of a given capability) must be used when adding collections and capabilities to the user account. These functions ensure that the transaction executes without problems. check() getLinkTarget() Use Panic Panic is a built-in function in Cadence that allows you to terminate a program unconditionally. This can occur during the execution of your smart contract code and returns an error message, which makes it easier to understand when something does not go as expected. When declaring variables, it is possible to define them as optional; meaning, if they are not of the specified type, they have a value of nil. Thus, in Cadence, it is possible to use two question marks followed by the function when querying the value of a particular variable or function that returns an optional. panic("treatment message") let optionalAccount: AuthAccount? = //...
let account = optionalAccount ?? panic("missing account") This command attempts to return the value with the specified type. If the returned value is the wrong type, or nil, the execution aborts, and the selected treatment message displays on the console. ??panic("treatment message") Anti-Patterns Although Cadence is designed to avoid many of the potential bugs and exploits found in other blockchain ecosystems, there are some anti-patterns developers should be aware of while building. Listed below are a few important ones to consider. For a complete list of anti-patterns, . check out the Flow documentation Failing to Specify the Type When Using the Borrow Function Developers should use the borrow function mentioned above to take advantage of the features available in a capability. However, it should be clear that users can store anything in their memory. Therefore, it is vital to make sure that what is borrowed is of the correct type. Not specifying the type is an anti-pattern that can end up causing errors or even breakage in your transaction and application. //Bad Practice. Should be avoided
let collection = getAccount(address).getCapability(ExampleNFT.CollectionPublicPath)
                    .borrow<&ExampleNFT.Collection>()?? panic("Could not borrow a reference to the nft collection")

//Correct! 
let collection = getAccount(address).getCapability(ExampleNFT.CollectionPublicPath)
                    .borrow<&ExampleNFT.Collection{NonFungibleToken.CollectionPublic}>()
                    ?? panic("Could not borrow a reference to the nft collection") Using AuthAccount as a Function Parameter For a transaction in the preparation phase, it is possible to access the AuthAccount field of the user. This object allows access to the memory storage and all other private areas of the account for the user who provides it. Passing this field as an argument is not recommended and should be avoided, as cases where this method is necessary are extremely rare. //Bad Practice. Should be avoided

transaction() {
	prepare(acct: AuthAccount){
		//You take sensitive and important user data out of the scope of the transaction prepare phase
		ExampleNFT.function(acct: acct)
	}
} Using Public Access Control on Dictionaries and Arrays By storing dictionaries and array variables in your contract with scope, your smart contract becomes vulnerable, as anyone can manipulate and change these values. pub/access(all) Creating Capabilities and References Using the Auth Keyword Creating capabilities and references with the keyword exposes the value to downcasting, which could provide access to functionality that was not originally intended. auth //AVOID THIS!
signer.link<auth &ExampleNFT.CollectionPublic{NonFungibleToken.Receiver}>(
    /public/exampleNFT,
    target: /storage/exampleNFT
) Conclusion When developing on the Flow blockchain using Cadence, it helps to be aware of design patterns, anti-patterns, and best practices. By following these best practices, we can ensure a consistent level of security throughout the Flow ecosystem, thus providing the best experience for users. For a more thorough understanding, . read through the Flow documentation Have a really great day!

Flow & Cadence Best Practices, Patterns, and Anti-Patterns

How To Build An NFT Minting Dapp On Flow

Smart contract development is no different than other types of software development. Code is written to perform a certain task, and there are tools that help make this process easier. The Ethereum ecosystem contains many mature tools to help build Web3 projects, but what about a newer ecosystem, such as Flow? If you’ve been following along with this series so far, you’ll know that the Flow blockchain is optimized for digital asset creation and management. Additionally, its smart contract language, Cadence, improves upon other languages’ pitfalls through its resource-based approach and a strong, static type system. In this article, we’ll take a look at the essential tools smart contract developers can use to make building on Flow easier—tools such as CLIs, IDE extensions, client libraries, local networks, and more. We’ll also contrast these to Ethereum tools you may already be familiar with, so if you’re making the switch to Flow, you’ll know exactly what to expect. Command-line Interfaces Command-line interfaces (CLI) are the bread and butter of software development. They are intuitive for most developers and integrate easily with other software. This easy integration applies to smart contract development as well. For example, if you need to quickly deploy a contract to test it or run it with different accounts, a CLI can help immensely. And later, when you want to add the deployment process to a CI/CD pipeline, you’ll be happy to have a simple CLI tool you can automate with shell scripts. On EVM-compatible networks like Ethereum, Truffle and Hardhat both offer powerful tools for these tasks. The is used for almost all actions with Hardhat, while the __ __enables developers to quickly interact with their smart contracts via JavaScript without having to write script files. Hardhat Runner Truffle Console is the primary tool for developing, testing, and deploying smart contracts written in Cadence to the Flow network. In addition, it’s the interface you use when interacting with the Flow blockchain, such as creating and checking accounts, signing transactions, or automating tasks with scripts. The Flow CLI Unlike Ethereum, where you would generate an address to interact with the blockchain, Flow requires you to have an account. This account holds your smart contracts, tokens, and keys, and is necessary for interacting with the blockchain. You can . easily create accounts using the Flow CLI IDE Extensions Next, you want to write some code, and languages like Cadence and Solidity offer static type checking that gives you some helpful information about how your code will behave in your editor. While Solidity comes with a fundamental type system that prevents you from mixing different number types, Cadence goes a few steps further and introduces the concept of ownership. You might know this from Rust, but the basic idea is that Cadence has resources, like NFTs, that can only be owned by one address. A Cadence IDE extension will notify you about issues with your NFT transactions right at the point when you’re writing the code, while also offering syntax highlighting, code completion, and type checking. Linters You might know linters from languages like JavaScript, where no static typing is available. In this context, a linter helps to prevent common errors and to aid developers in following best practices. The same is true for , a linter tool for Solidity. Again, Solidity’s static type system is very rudimentary and doesn’t prevent many errors while using the language. Solhint comes to aid here and provides tips on top of the type system to avoid misuse. Solhint The Cadence language has a much more sophisticated type system and comes with more help than Solidity. A correctly typed Cadence smart contract is more secure than a correctly typed Solidity one. The typical linter functionality is built right into the Cadence language itself through its type system, but if you want to run type checks on multiple Cadence files inside your CI/CD pipeline, the tool can help. Cadence lint Local Networks A local network, or a network emulator, is a tool that will run a blockchain network on your development computer, so you can test in a clean environment and not risk pushing unfinished smart contracts to a live blockchain. A local network also has lower latency and allows you to control the block creation, so you can step through everything that happens when your smart contract executes. When developing on the EVM, you probably know and use or Ganache for this task. Both tools simulate a blockchain environment on your local machine and allow you to fork a version of mainnet to interact with real accounts and contracts. the Hardhat Network Flow offers a similar feature called that simulates the real Flow network but gives you to interact with. It enables account storage limits, setting initial FLOW token supplies, and enabling persistent state between restarts. This powerful tool is used via the Flow CLI mentioned above and together, they provide all the features developers need to build fully functioning dapps and the environment to test them in. the Flow Emulator more options With the , all one has to do to start the emulator is type the command flow emulator in their terminal. Flow CLI installed Testnet Faucets When developing smart contracts, you typically need crypto tokens to deploy and interact with your code. Otherwise, how will you test transactions? Flow, just like Ethereum, has__ __ that comes with that drips you free testnet FLOW or FUSD for development. a testnet a faucet Additionally, Blocto Swap is a multi-use tool that makes creating an account on Flow simple for users. All one has to do is enter an email address. Blocto Swap allows users to easily exchange their tokens for different types to use in testing. This tool is also a handy way to get FUSD if that collection is not already initialized in the account. : tokens on a testnet hold no value outside of testing. Remember Automated Testing Cadence and Solidity both have test automation tools that allow you to write your tests in JavaScript. The Hardhat development tools use the Chai test runner and supply you with and for the EVM. smart contract matchers network helpers Cadence has that use as the base, but they’re framework agnostic. So if Jest isn’t your thing, you can use a different test runner. its own tools Jest Blockchain Explorers Another vital part of all blockchain networks is the block explorer—a tool that allows you to check out everything that happens on-chain. For the Ethereum network, you might know . It’s a web application that lets you browse mainnet and testnet transactions and addresses. Etherscan Flow comes with a much more powerful tool, ! Flowser Flowser (Flow Browser) is a web application, but you can run it locally. It allows you to browse both the Flow mainnet and any local network you start with the Flow Emulator. It even comes with a GUI to configure and start an emulator and manage your development wallets. However, if all you need to do is check transactions or browse on the Flow mainnet or testnet, then the traditional block explorer__ __ will suit your needs. Flowscan Additionally, the tool allows users to inspect accounts and their various attributes, such as balances, keys, and any contracts they may contain. flow-view-source Interfacing with JavaScript To build a decentralized application (dapp) for your smart contract, you need a bridge between the blockchain network and the web. Flow and Ethereum both come with Webpack integrations to solve this problem. will automatically reload your application when you change your Solidity code, so your frontend always runs with the current version of your smart contract while in development. The Solidity Loader Cadence offers similar features via its and . Webpack plugin the Cadence utilities Additionally, the (FCL) JS is one of the best ways for a developer to quickly start building on the Flow blockchain. This package makes interacting with wallets and smart contracts simple and secure, while providing all the tools necessary to create fully functioning dapps. Flow Client Library Playgrounds Being able to test your code in environments without having to invest the time in creating an entire project enables developers to quickly figure out what works and what doesn’t. To that end, Flow has the . Not only is it an excellent resource to iterate through ideas quickly, it’s also a great environment to learn in, with tutorials included to teach important concepts and how to build common projects. Flow Playground Although Ethereum doesn’t have any projects exactly like the Flow Playground, there are a few you could take advantage of to create a similar experience. The online Solidity code editor, , provides an environment to quickly build and test smart contracts. Additionally, you could follow along with the to help get you up to speed with Solidity and Remix. Remix Developer DAO Academy Summary Software development, and smart contract development in particular, is a complex process that consists of different vital steps. Planning, coding, testing, deploying, and maintenance are all important parts of the process, and having the proper tools at hand makes things easier. Although Flow has a younger ecosystem compared to Ethereum, the tools and libraries available are mature enough to help speed up the development process. From command-line interfaces and IDE extensions to local networks and block explorers, Flow has all the tools an Ethereum developer might be expecting and more. Additionally, the type system and built-in features of the Cadence smart contract language offer controls that Solidity can’t offer without additional tools such as linters. Even then, the value those Solidity tools delivers is inferior to the features Cadence provides natively. Overall, the Flow ecosystem comes with for each step of the development lifecycle. To get started building on Flow, check out their . Developers are also encouraged to share their own tools with the ecosystem, contribute to already existing tools, or to build your projects. all the tools you need Developer Portal apply for grants For a list of other great tools in the Flow ecosystem, . check out this Github repo Have a really great day!

Building Easy Workflows For Web3 Using Flow & Cadence

This is the official HackerNoon wiki for Flow. As part of our , this living wiki displays on . If you’d like to suggest edits to our official Flow wiki, please submit them in comment field below, a real human editor will read and review your suggestions for accuracy and publication. coin price pages Flow crypto price page Flow is a created to solve the of games, apps, and digital assets. Flow was created to provide a network that maintains stable . blockchain solution of scalability decentralization Flow separates data and jobs between five node types rather than having each node store all of the data that is on the blockchain. This reduces the effort and time needed for the nodes to carry out their operations. Flow also gives consumers and developers the opportunity to use features such as human readable security and . The blockchain uses the . upgradable smart contracts Proof of Stake algorithm History of Flow In 2017, Dapper Labs created the first blockchain game based on . The game centerd around collecting as well as breeding digital cats. The game became so popular it brought the entire Ethereum network down. This made Ethereum transactions halt for several days before the entire system was resolved. Cryptokitties Ethereum From this, came up with an idea for an ideal blockchain for collectibles and games that dealt in . This ideal game needed to be scalable to avoid taking down networks in case of high traffic like it had done on Ethereum and needed to be affordable even when in heavy usage. Dapper Labs crypto Dapper Labs is responsible for the revolution with Cryptokitties. The Flow playground by Dapper Labs was launched in 2020 and gives developers the ability to make and trade NFTs. Non-Fungible Token (NFT) Dapper Labs introduced the flow blockchain in September 2019. They carried out a public sale on Coinlist that went on to raise$18 million. The company has grown and expanded since then to include company partnerships with Google, Samsung, Ubisoft, NDA Top Shot, NFL, and UFC. Biggest Claim to Fame Flow chooses to use multi-node architecture instead of sharding. Sharding is processing bits of data on the blockchain instead of processing the entire database. Dapper Labs felt sharded blockchains were unsuited for creating environments that are composable for smart contracts. Composable contracts allow developers to build on each other's work quickly and easily. The Flow networks work with multi-node architecture that works better than sharding and does not have as many negative effects on the system and operations of the network.. This means each node gets a specialized task e.g. collection, consensus, execution, or verification instead of each node is required to do multiple tasks. This makes for better efficiency throughout transactions. Developers were very involved in the creation of Flow. Due to the experience they had on Ethereum with Cryptokitties, they have made sure developers can work within Flow easily and efficiently by ensuring developers have created a space that is easy to work within. Flow has its own designing language and offers help to developers as they learn the system and the language. are easy to upgrade on Flow. Developers have time to observe their contract and how it behaves before they make it unchangeable. This is not a quality Smart Contract platform like Ethereum provide where once a contact is submitted it is immediately unchangeable. This is a quality that makes people prefer Flow over other similar platforms. Smart contracts Biggest Criticism of Flow The biggest criticism of the Flow network is they have a dilemma when it comes to carrying out verification of claims. Verification is still typically done by people and people can be fallible. The issue of paying off or buying off of problems and people who can solve them is unfortunately still very possible and plausible. Flow does not have enough steps to ensure this could not happen. They have taken commendable steps towards reducing the possibility of it happening but it still is a big issue. The Flow Team Flow was created by Dapper Labs. The founders of Dapper Labs are Rohan Gharegozlou, Mikhael Naayem, and Dieter Shirley. Dieter Shirley is the Chief Technical Officer and lead architect of Dapper Labs. Mikhael Naayem is the Chief Business Officer at Dapper Labs. Rohan Gharegozlou is the CEO of Dapper Labs and founder of the venture studio Axiom Zen. In Conclusion The Flow blockchain has a problem it wanted to solve and has worked very hard to solve it. Their approach to the blockchain was unique and designed for consistent long-term use. They are yet to catch up with the bigger, more established networks but are up and coming in it. They could become bigger in the future as all signs point to them trying to solve the issues they have with the system and improving them. This is the official HackerNoon wiki for Flow. As part of our , this living wiki displays on . If you’d like to suggest edits to our official Flow wiki, please submit them in comment field below, a real human editor will read and review your suggestions for accuracy and publication. coin price pages Flow crypto price page

Flow $FLOW Wiki: Coin History, Techstack, and Crypto News

In the fast-paced world of Web3, there is no shortage of innovative new technologies to explore. If you are a Solidity developer looking to build on a blockchain that is , then Flow is an option you can’t ignore. faster, safer, and more scalable than Ethereum Flow was built from the ground up as an alternative to slower, less user-friendly layer 1 blockchains with its own custom-built smart contract language, one optimized for creating and managing digital assets. This article will introduce the Flow blockchain in greater detail, unpack its smart contract language Cadence, and look at exactly why an Ethereum developer should consider building on Flow. What Is Flow? In 2017, a new Ethereum collectibles game, CryptoKitties, developed by the Canadian company , made headlines after it caused the Ethereum network massive congestion while only having 10,000 users. The developers at Dapper Labs quickly realized that the Ethereum network was not optimized to operate and scale a successful game, so they started working on an alternative. Dapper Labs The end result of Dapper Lab’s efforts is the —a decentralized and developer-friendly blockchain designed to scale without . Flow is highly optimized for the creation and management of digital assets such as NFTs. Flow Blockchain sharding The Four Main Pillars of Flow The Flow blockchain has four key pillars at its foundation: Multi-role architecture Resource-oriented programming Developer ergonomics Consumer onboarding These four pillars set Flow apart and help solve common challenges typically faced by other blockchains. Let’s look at each of these items in detail. Multi-role architecture Flow’s unique design uses a that allows the network to scale. This is achieved with a validator node that is separated into four different roles: collection, consensus, execution, and verification. Simply put, the collection node , the consensus node , the execution node , and the verification node the work. Every node still participates in validating transactions, but they each specialize in different stages of the process, effectively increasing the transaction throughput. multi-role architecture batches secures completes checks Resource-oriented programming Flow’s second pillar is . Cadence is a resource-oriented programming language that is used to develop smart contracts on the Flow blockchain. This optimized smart contract language uses a strong, static type system which helps minimize errors. It also allows pre- and post-conditions to be used, so developers can enforce expected behaviors. We’ll cover more on Cadence in the next section. resource-oriented programming Developer ergonomics Developer ergonomics is the third pillar of Flow. From the beginning, the Flow creators focused on supporting developers and making their lives easier. The Cadence smart contract language was built from the ground up to make creating and managing assets efficient and less prone to errors. Open-source tooling—such as the , , and —makes getting started on Flow a smooth process. Flow JavaScript SDK Flow Go SDK Flow Playground GUI Upgradeable smart contracts help minimize bugs in code, creating a more secure ecosystem overall (more on contract immutability below). Built-in logging support gives developers a means to trace a program’s behavior. This is a much sought-after feature that many blockchain ecosystems cannot provide. Consumer onboarding Creating a consumer-friendly onboarding experience for new users is the fourth pillar of Flow. Human-readable security ensures users make informed decisions when running transactions. For example, instead of signing a transaction of hashes or confusing numbers and letters, Flow’s human-readable transactions ensure a level of transparency, clearly stating what permissions a user may be authorizing. The account model for Flow also keeps users in mind. __ __feature built-in, optional, and modular smart contract functionality which enable more complex authorization controls or automated processes. These features in turn create a better experience by making sure users cannot lose their assets while also providing options for account recovery in case of lost keys. Additionally, multi-signature support equips wallets with added security by allowing users to regularly cycle old keys. Flow wallets What Is Cadence? Along with the faster, more scalable blockchain, Flow’s developer team created , . Digital assets are one of the most important aspects of blockchain development, and now there is finally a language that optimizes their creation and management. a new smart contract language Cadence Cadence’s syntax takes inspiration from other modern programming languages such as Swift, Kotlin, and Rust. It is the first high-level, resource-oriented programming language and utilizes a strong static type system. This effectively helps cut down on runtime errors and ensures expected behavior. What does resource-oriented mean? In Cadence, special data types, called resources, are based on linear data types and represent digital ownership of assets on Flow. These resources, such as NFTs, are stored in a user’s account, rather than reflected as a record on a public digital ledger, and can only exist in one place at a time. This means the ownership of digital assets on Flow is defined directly in the language itself, effectively removing the risks involved with storing balances on a centralized digital ledger. directly Additionally, Cadence improves asset management through the enforcement of strict rules that govern possible operations. Devs must define resource types with an ‘@’ symbol before explicitly moving, storing, or destroying them. This forced management of assets removes the possibility of losing or accidentally deleting an asset because of an error in the code and reduces human error. Cadence, similar to Flow, is built on pillars—this time, five of them: - Cadence uses a strong static type system, built-in ownership primitives based on linear types, and a foundational focus on asset management to ensure expected behavior of code and minimize attack vectors for hackers. Safety and security - The declarative nature of Cadence ensures developers are explicit with their intentions, making the code easier to read, write, and audit. Clarity - Cadence’s syntax and semantics are inspired by languages such as Swift and Rust, which make it familiar, while thorough documentation and efficient tooling create an approachable environment for developers to . Approachability quickly get up to speed - The Flow ecosystem provides to deliver support throughout the entire development lifecycle. Developer experience resources - The concept of asset ownership is built into the Cadence language itself through the use of resources, rather than a central ledger. Assets are directly tied to an account’s storage and can be freely transferred without a smart contract. Intuiting ownership with resources Why Should Developers Build on Flow? With all the protocol improvements introduced by Flow, they are clearly ushering in a new era of blockchain technology that focuses on developer acquisition and user experience. The available enable a productive development lifecycle, while their extensive __ __ensure devs coming from Ethereum, or new to Web3 in general, have a thorough understanding of the types of solutions Flow is optimized for. suite of tools architecture guidelines Tools such as the and __ __make getting started easier than ever. The FCL JS package makes wallet integrations extremely easy, while its powerful SDK provides all the tools necessary to create dapps quickly and securely. Flowser (Flow Browser) is one of the most innovative new blockchain development tools, allowing you to not only inspect the states of Flow mainnet, testnets, or emulators, but also manage custom emulators and wallets through its GUI. Flow Client Library (FCL) JS Flowser Additionally, the Flow blockchain __ __just as much as other aspects of the protocol. And for this reason, it is arguably one of the most eco-friendly blockchains on the planet. Not only do they use less energy than every proof of work blockchain, but most proof of stake blockchains as well. This is thanks to its consensus mechanism and unique multi-role architecture mentioned earlier in this article. To put its energy use into perspective, for the energy cost of performing one Google search, you could create 12 Flow NFTs. prioritizes environmental impact So let’s dive a little deeper into why developers should build on Flow by comparing it to Web3’s largest contributor, Ethereum. Flow and Ethereum: A Closer Look To get a better idea of how Flow compares to Ethereum, let’s take a closer look at a couple of important aspects and differences. Transaction fees and speed Ethereum is notorious for having extremely expensive transaction costs when network demand is high. The high fees are a mechanism used by the network to keep transaction volume at a manageable level. When blockspace demand is high, the fees go up to discourage people from deploying. Additionally, blocks on Ethereum are confirmed every 12 to 14 seconds, with finalization occurring within 6 blocks, or just over a minute. This leads to a maximum transactional throughput of ~15 transactions per second. In order to serve the needs of millions of users, significant improvements must be made. Flow, on the other hand, was created with these challenges in mind. The multirole architecture mentioned above enables block finalization to occur roughly , which leads to approximately . The fees to deploy and transact on mainnet are also just a fraction of what they would be on Ethereum’s mainnet. every 2.5 seconds 100 transactions per second Contract immutability Depending how you look at it, the immutability of Ethereum smart contracts once deployed can either be a good thing or a bad thing. On one hand, not being able to edit smart contracts after they’ve been deployed ensures a certain level of trust. It confirms that the code you are interacting with can’t be changed or repurposed once it’s live. On the flip side, code is rarely deployed in perfect shape, even with teams of incredibly skilled coders. Any small imperfection can lead to massive breaches, resulting in major losses. In order to fix a flawed smart contract, developers must deploy a whole new contract and ensure their user base uses that one instead. Flow takes the above scenario into consideration with their approach to smart contract immutability. When contracts are deployed to the Flow blockchain, they are mutable by default. This means that developers can easily make changes should any complications arise with the live contract. Of course, this doesn’t imply smart contracts skip the testing phase altogether. Teams developing contracts will typically use software development best practices to test and iterate on contracts in testnet before final deployment to mainnet. After some time has passed on mainnet, and the smart contract has met any final testing or security checks, developers have the option to revoke the keys to the account holding the smart contract. This process eliminates the ability to make any further changes, effectively making the smart contract immutable. The ability for smart contract developers to enforce immutability on any contract at any time is a clear advantage Flow has over Ethereum and other blockchain networks. Growing Ecosystem Beyond the technical advantages, Flow’s community is growing at a rapid pace. A strong developer ecosystem, accessible network participation, and content partners are all helping with awareness and leading to a steady increase of transactions on Flow. June 2022 was a record-breaking month for Flow, reaching close to 34 million transactions. Most people think of NBA TopShot when they hear Flow blockchain; however, Flow has seen rapid expansion in the DeFi and gaming space. Leading the gaming space, and have the highest sales according to , a Flow Blockchain aggregator. DeFi projects include decentralized exchanges , built by Blocto, and . You can take a look at some of the other projects that have been built on Flow . Chainmonsters Zeedz Flowverse BloctoSwap IncrementFi here The Flow ecosystem also received $725 million from the __ __to help developers who are building on Flow. With the added incentive to build, the number of projects deciding to build on Flow will continue to bloom. Flow Ecosystem Fund With the technical advantages, increasing popularity, and availability of funding on Flow, . the need for Flow/Cadence developers has never been higher Conclusion Following the success of CryptoKitties, the Dapper Labs team quickly realized that Ethereum was not in a state to support a massively successful blockchain game. Their struggles with Ethereum led to the creation of the Flow blockchain and Cadence smart contract language, both optimized for the creation and management of digital assets. There has never been a better time for Ethereum and Solidity devs to start building on a faster, safer, and more scalable blockchain. If you’re interested in learning more about developing on Flow or how to use Cadence, you can visit the new__ __. There, you’ll find more information on how to get started. developer portal Have a really great day!

From Ethereum To Flow – An Introduction To The Flow Blockchain

Since the introduction of smart contract technology, Solidity has been the coding language of choice for smart contract developers. However, if you’re a Solidity developer, you already know it has drawbacks. Among other flaws, major security concerns can arise from the simple mishandling of certain data types, and there are no built-in access controls. A new smart contract language developed for the Flow blockchain, , learns from Solidity’s oversights and natively solves many of its inherent problems. And if you already know Solidity, it’s straightforward to learn! Cadence This article introduces the Cadence smart contract language, details how it improves over Solidity, and then walks through a side-by-side comparison of both languages on some common smart contract examples. By the end, you should be comfortable with Cadence and ready to get started on Flow! About Cadence Cadence is the programming language that powers the Flow blockchain, which was originally created by to support large-scale crypto games and NFT projects. (You’ve probably heard of NBA Top Shots—one of their most successful projects.) Its syntax might be familiar, since it was inspired by popular modern languages such as Swift, Rust, and Kotlin. Cadence is and , with a resource-oriented approach and capability-based security model. Dapper Labs statically strongly typed All of this means that Cadence is . highly optimized for digital asset creation and management The most substantial innovation Cadence introduces is its . This approach makes it significantly easier to create, track, and manage a user’s assets. Instead of relying on a central public ledger as the source of truth (as Ethereum does), assets are tied directly to a user’s account storage. So an asset created as a resource, such as an NFT, can only exist in one location at a time. This ensures they only have one owner—either an externally owned account or a smart contract. resource-based paradigm How Cadence Improves Over Solidity Cadence improves over Solidity in many ways. Let’s look at three examples—small coding mistakes, security and access control, and contract deployment. Those small coding mistakes Some of the biggest issues with Solidity usually stem from the smallest mistakes. For example, initializing a variable with just a default value—although convenient at times—can lead to unexpected results if that variable is not changed. And fixed-range data types can lead to potential underflow or overflow situations, which would be disastrous if that data type represents a monetary value. In Cadence, variable values must be set upon initialization, removing any unwanted results from default values. Additionally, integers in Cadence are automatically checked for underflow or overflow conditions, whereas you would need to inherit OpenZeppelin’s or use a version higher than 0.8 with Solidity. safe math library Security and access control When it comes to security and access control, Solidity requires you to create custom modifiers or inherit other security-based smart contracts, but also has many functions that are public by default. With Cadence’s , accounts can only perform functions they have access to. This means Cadence has access control fundamentally built into the language itself. Also, methods defined on resource objects in Cadence cannot be susceptible to , something Solidity developers have to be keenly aware of when creating the flow of their logic. capability-based security model reentrancy attacks Smart contract deployment When issues in Solidity smart contracts are found, developers are unable to fix them without deploying an entirely new contract. And even then, the vulnerable contract still exists. Developers must ensure their user base switches over to the new contract. In Cadence, is built in and transparent. When the code is declared secure and final, the contract can be made immutable by removing the keys from the owner of the smart contract. smart contract upgradeability Overall, Cadence is a safer and more secure smart contract language that leaves less room for error. Now let’s look in detail at the differences between smart contracts written in Solidity and Cadence. We’ll walk through a simple Hello World contract and then a more complicated NFT implementation. Simple Contract Let’s start with an all-time classic. We’ve all written “Hello World” in multiple languages, so it’s an easy intro to Cadence. Let’s go through it step by step. Contract Definition First, we have the contract definition. The obvious difference is that the Cadence contract has an access control modifier: in this case, pub. This modifier ensures that everyone in the Flow network can access the contract, the default behavior for Solidity contracts. However, in Cadence, we could also set the access control to . This limits contract access to the . Here we already see a major difference between Flow and Ethereum. We don’t simply deploy contracts to the Flow blockchain; we deploy them to our account storage. On the Flow blockchain, each account is initialized with storage, where resources and structures can be stored. This storage has its own permissions, which allows us fine-grained control over who can execute the methods of our contract. access(account) account that deployed that contract Contract Variables The next line defines a string variable scoped to our contract. Semicolons are optional in Cadence, and a keyword is used to define the variable. let Cadence has two types of variables—mutable and immutable. Variables created with are immutable, or otherwise known as constants; we can only set them once, and they cannot be changed for the lifetime of the contract. We define mutable variables (ones that can be changed) with the keyword. let var In this case, we set the variable value in the init method, because Cadence ensures that this method is only called once for every contract deployment. Methods The Cadence equivalent to Solidity’s is the method. This method is called exactly once—at the time a contract is deployed. constructor init Inside the init method, we set the value for our greeting variable. While Solidity writes to contract variables by default, Cadence writes to local variables and requires you to use the self-object to access contract variables. This decision protects against you accidentally writing to a contract variable when making a typo. The second method of our contract returns the greeting variable. In both Cadence and Solidity, we have to declare access for the method to be public, and both languages require us to define the return type. In this case, it’s a string. But Solidity requires us to be more low-level here. It requires us to explicitly tell it where the string is located. It also makes us mark the functions as view, so that we don’t accidentally modify the state of the blockchain. Cadence, on the other hand, doesn’t need that low-level control, since it is strongly and statically typed. Potential errors are caught before the program is run on-chain, making the whole method declaration more readable by removing redundant keywords. NFT Contract Next, let’s look at a basic NFT contract from both languages: Since both languages have different approaches to this example, let’s look at them separately: first walking through the Solidity example, then Cadence. Solidity In Solidity, an NFT is basically a list of IDs. You must keep track of these IDs inside the smart contract and increment them manually to ensure uniqueness. Solidity doesn’t know anything about NFTs or their uniqueness. It’s just a list of IDs mapped to their owners, all managed manually within the contract. This leaves room for error if the ID incrementation is improperly handled, potentially resulting in multiple NFTs having identical IDs. In the example, the NFT doesn’t have any additional data attached, but you could add another mapping ID to a URI. The contract ensures every newly minted NFT is mapped to an owner's address. This is a simple example, of course. Usually, you would need to extend several interfaces to get a remotely secure NFT contract and features like metadata used to attach the well-known JPGs to your NFT, but the basic mechanisms are the same. Cadence Now, let’s look at the Cadence version and how it improves upon this Solidity example. Resource Definition The Cadence example starts with a resource type called . Notice the @ symbol in front of ? This symbol is required, as it ensures the usage and behavior of resource types will remain explicit. NFT NFT We can create instances from a resource, and it can have attributes just like a struct. The difference from a regular struct is that a resource is a special type that handles ownership in addition to the data it stores. Inside the resource type , there is an id field. The field is an integer, , and it is a unique id given to each NFT resource. This will be different for each NFT resource, meaning the resource cannot be duplicated or combined. Next, the field is initialized using the function. NFT id UInt64 id id init Similar to how ensures only one function can modify a variable, Cadence ensures the same for its resources. Rust’s borrow checker Resource Creation When we create a new resource, we have to move it around storage locations. Our smart contract will not run properly if we leave the resource as is, so this forces us to be deliberate with resources and their storage locations. This form of control also ensures that resources never get lost or accidentally deleted; they can only be in one location at a time. When we call the mint function, it will create a new instance of our resource. This function returns a resource with a type of and takes in the field, , from the resource that was defined earlier. The keyword is a bit like the new operator in object-oriented programming, creating a new resource. The , or move-operator, makes it explicit that this resource isn’t available at the source after we called it. NFT NFT id create <- Storing the Resource The variable will point to the account we used as a deployment target for our contract. As we learned before: smart contracts aren’t deployed in a global namespace on the Flow network, but in special on-chain storage that belongs to your account. So, the smart contract knows which account it’s been deployed to and can use that information in its methods. self.account In this example, we use the account’s save method. In the final function, we move the resource into the methods first argument and tell it which path inside the account should store our NFT. init save Since our NFT is a resource, no entity on the Flow network can copy it; we don’t have to keep track of its uniqueness explicitly. Summary Cadence is a fresh take on smart contract programming languages, optimized for asset creation and management. It’s a modern alternative that mitigates the deficiencies of Solidity through such means as forced management of variables and resources, security and access controls at a foundational level, and the ability to upgrade smart contracts before making them immutable. Cadence opens you to the possibilities of the Flow ecosystem, and incorporates many features from languages like Rust. So, if you are a developer looking to write smart contracts in a fundamentally safer and more secure language, Cadence is an excellent option. To learn more, check out the and . Cadence Documentation Flow Developer Portal Have a really great day!

Smart Contract Head to Head — Ethereum vs. Flow

Contrato inteligente frente a frente: Ethereum vs. Flow

Tête à tête de contrat intelligent - Ethereum contre Flow

स्मार्ट कॉन्ट्रैक्ट हेड टू हेड — एथेरियम बनाम फ्लो

スマート コントラクトの直接対決 — イーサリアム vs. フロー

Contrato Inteligente Frente a Frente — Ethereum vs. Flow

Hợp đồng thông minh đối đầu - Ethereum vs.

智能合约头对头——以太坊 vs. Flow

This Slogging thread by Abeer, Sara Pinto, Jack Boreham and Mónica Freitas occurred in slogging's official #random channel, and has been edited for readability. Abeer Jan 13, 2022, 4:14 PM “Bringing your A game.” It goes by many names. Martial artists call it Mushin. Psychologist Mihaly Csikszentmihalyi coined the term Flow to describe it. A state of hyperfocus where you perform at an amazing level. While everyone’s different, there’s a lot to learn from how each of us individually tap into this wellspring of focus. So, how do you get in the zone? Personally, I usually start with a short meditation lasting a few minutes to calm my mind. Then I set an objective or goal for the next hour. I set a Pomodoro timer for an hour so I’m committed to focusing on this one task. Then I find a simple instrumental song that plays on repeat for the entire hour. I’ve noticed that video game soundtrack music works really well for me. The repetition of the song sort of keeps a rhythm to which I can work to without taking my attention away from the task at hand. Somehow all this manages to get me into a nice flow fairly reliably. Sara Pinto Jan 14, 2022, 2:45 PM I'm still trying to find what works best for me. But for now, the first step of my method is to clean and organize the space where I am. Then, I arrange the work I have to do, by priority, so I can feel a little in control of what has to be done. I put some music - I've tried every type, but I don't have a specific one that always works, it has to depend on my mood. And then I just work. I like to challenge myself to finish the work in a certain amount of time and so on, so I never used a Pomodoro timer. I thought it had to always be 25min Abeer Jan 19, 2022, 5:45 PM I can definitely understand needing a clean work environment. There were times I had to move rooms because my room was just too messy at the time. 😅 Arranging work by priority is definitely a smart move so you don’t trick yourself into procrastinating on the important tasks by focusing on the trivial tasks. From my understanding, standard Pomodoro is 25 minutes of work and a 5 minute break. A lot of people including myself have issues with this ratio and tweak it to fit their needs. For me, it takes 15-20 minutes to really get into the flow of things so it seems silly to stop 25 minutes in. Usually between the 45 minute to an hour mark, I’m quite mentally fatigued so that’s when personally a break works best. That 5 minute break feels like nothing to me, however, so I usually like to take a full 20 minutes to do something else and feel refreshed before I go back for another round. Are there any ways that seem to work for others but never work for you? Sara Pinto Jan 20, 2022, 11:31 AM I think having it all organized, from the room to the priorities just gives you a sense of control over the tasks, and it gives me motivation! My thoughts exactly! It takes me some time to organize and feel like working, so 25 would never do. I sometimes end up using the method like you, in an extended way. Ah yes! When it comes to music/silence. I'm still trying to figure out how people work with no sound at all, I think I would just have to talk to myself haha. Also, people that work while listening to instrumental only. That's one thing that I've tried and never seems to work, but some people swear by listening to classical music, it must be just me haha Jack Boreham Jan 14, 2022, 5:39 PM For me its complete silence. Nothing around just me, my laptop and my ideas. 😂 Abeer Jan 19, 2022, 5:49 PM Silence makes perfect sense. I’m sure that’s one of the reasons people like to study/work at libraries. Mónica Freitas Jan 14, 2022, 7:54 PM For me, it's a high-energy playlist, coffee and putting the heavy lifting between the times of the day I know I have more mental energy - from 10 am to 4 pm. Abeer Jan 19, 2022, 5:52 PM I totally get the high-energy playlist. 😂 Synchronizing your heavy lifts with your energy patterns and Circadian rhythm is very clever. How did you figure out when you have the most mental energy? Did you track it somehow? Mónica Freitas Jan 19, 2022, 9:20 PM I need speedy songs to trick myself into having energy ahahaha To be honest, I only figured this out in the last couple of months, once I started working remotely. I noticed that I was super productive and creative right before and after lunch (coincidence or treat?). So I use that time to make those more mentally demanding and draining tasks. I never actually tracked it consciously. It was just getting more aware of my mental patterns. But I didn't know there was a name for it. So, there you have it! How do you get into your A-Game state?

Getting Into a Flow State and Bringing Your A-Game

Return to what works and jettison the fads The software industry is in as deplorable a state as American politics. It is driven by destructive and insane protocols and is not working. The (1) vitality of cognitive focus and (2) the destructiveness of interruptions are both now entirely unrecognized and it is these understandings that enabled the past greatness of this crippled industry. Software development does not deserve the honor of “engineering.” It is further from engineering than economics is from science. Engineers don’t have “personal styles” for blueprints and they have standard procedures for testing that are determined by recognized regulatory bodies. Learn To Focus The industry focus has shifted to testing because people are writing lousy code loaded with bugs.  People write lousy code because they can't concentrate.  They can't concentrate because they are constantly interrupted.  They are constantly interrupted because of meetings, a noisy environment, and a peculiar outlook of software development as some sort of social activity. The solution is not wasting time on writing tests.  The solution is better working conditions. Better Working Conditions The return to good software development requires several strong and unhesitant steps, foremost of which is: Flow the aggressive and unapologetic restoration of , prolonged and unbroken concentration, as the primary goal of software management.  This begins with a steep reduction in the number of meetings and routine cancellation of the few that remain. The items of this manifesto are: The removal of on software practices, specifically all aspects of Extreme Programming and most of Test-Driven Development. These are counterproductive and in some cases sadistic all influence of Kent Beck The methodologies from software development.  These are little more than rebrandings with additional meetings elimination of Agile and Scrum The shift of emphasis and the restoration of dedicated QA teams embedded in development teams from unit testing back to blackbox testing The as something prerequisite to all serious work and the elimination of the idea that design is something done in tests restoration of software documentation the termination of managers who impose social programming practices, particularly pair programming The replacement of open offices and noisy social settings with A software development office should sound like a library private offices of single occupancy. The elimination of requiring rush hour commutes compulsory morning meetings the and the aggressive elimination of interruptions of all kinds and the from having grown up with instant gratification in their lives and consumption of entertainment institutional cultivation of extended attention spans termination or reassignment of engineers who cannot concentrate the restored recognition of valuable individual contributors of high capacity for detail and responsibility the elimination of in software work sports and financial metaphors The jettisoning of and a return to accurate naming conventions in communication bad nomenclature and misleading neologisms the in code formatting and software design and their replacement with rigorous and technically-justified patterns of work as genuine engineers use elimination of the notion of “personal styles” the exploration of new and deprecated , including but not limited to work from home and excuse from recurring and other meetings factors enabling Flow The alternative is to let what few companies are saddled with the nonsense currently in vogue outstrip all those burdening developers with counterproductive fads and putting them out of business, leading to extended joblessness. not Resources Justifications for the recommendations above are detailed in the articles below. The above document represents the conclusions taken from the arguments I have presented separately. Please read them before retorting with uninformed rage.  ’’Your wrong” is not a rebuttal. The Magnificence of Flow Software Development Isn't About Unit Tests Why Software Testing is So Important Test-Driven Development is Fundamentally Wrong Part I Test-Driven Development is Fundamentally Wrong Part II

The Flow Manifesto

Photo by on Sergey Pesterev Unsplash is the prototypical response when asking a software engineer for advice, no matter how straight-forward the problem may seem. When asked “Should we choose TypeScript or Flow for our next React Native project?” however, the answer only depends on one variable: . “Well, it depends” whether or not you work at Facebook It’s interesting to consider how we got here. The project team evaluated Flow vs TypeScript for our new React Native app almost three years ago. At the time, TypeScript didn’t support React well, didn’t allow for a gradual opt-in, there was no Babel support, and VSCode wasn’t the editor providing the best JavaScript development experience on the market. None of these factors are true today. But why bother to migrate? TypeScript has a lot of value to offer making the switch highly attractive: More “future proof” Higher OSS adoption & better RN + library support Awesome developer experience (VSCode) Consistency with other department projects Easier to hire for So, we forged ahead! But how’d it go? Before: 50K SLOC, 84% Flow Coverage $ npx sloc app
---------- Result ------------
Physical :  57903
Source :  50859
Number of files :  709
----------------------------
$ npx flow-coverage-report  -i percent: 84 %
$ time flow check
flow 3.64s user 2.31s system 32% cpu 18.458 total read 'app/**/*.js' Getting Started The first step we took was to update our JS tooling configuration. For our project, the procedure was relatively straight-forward, guided mostly by simply copying the configurations directly from a newly instantiated TypeScript template project using the . react-native cli Prettier & ESLint { : } "parser" "typescript" One used to have to deal with TSLint when chosing TypeScript but thankfully , so it’s an easy choice in 2019—just stick with ESLint! TSLint is deprecated Literally no changes necessary (for our usage anyway, and that included plugins and custom rules!) Done. Next. Bonus Aside: Removing Black Magic module imports Did you know that you can import JavaScript modules relative to a package.json file using the name attribute in the json file, no plugins required? Black magic! But it was useful black magic! To accomplish absolute path imports (i.e. we included in our project a in the (and several others as well for a total of 4 package.json’s): import Foo from ‘app/ui/components/Foo') package.json /app directory { : } "name" "app" This even works when importing from other folders in the tree (meaning you can import from outside of the ‘app’ folder). app/components/Foo Well, TypeScript doesn’t like this black magic fuckery and couldn’t figure out our imports :(. So, we deleted our extra package.json files and chose to use babel instead. Babel With built in Babel support for TypeScript in Babel 7, converting our babel configuration from Flow to TypeScript was a process of simply removing unused plugins (like ). @babel/plugin-transform-flow-strip-types Here’s our final Babel.config.js, complete with less magical module resolution. .exports = { : [ ], : [
        [ ,
            { : [ ], : { : },
            },
        ],
    ]
} module presets 'module:metro-react-native-babel-preset' plugins 'module-resolver' root '.' alias app './app' tsconfig.json While not strictly required for running your React Native app (Babel will just strip/ignore the TS syntax anyway), the tsconfig is required for using the TypeScript compiler (and VSCode tooling) to detect type errors. Thankfully, we got 90% of the way there by simply copy-pasting the tsconfig from a boilerplate new React Native project. However, we also include some files in our project, which require some additional configuration. .json { : { : , : , : , : , : , : , : [ , ], : , : , : , : , : , : }, : [ , , , ,
  ]
} "compilerOptions" "baseUrl" "." "allowJs" true "allowSyntheticDefaultImports" true "esModuleInterop" true "isolatedModules" true "jsx" "react-native" "lib" "es6" "dom" "moduleResolution" "node" "noEmit" true "strict" true "target" "esnext" "resolveJsonModule" true // Required for JSON files "skipLibCheck" true "exclude" "node_modules" "e2e" "**/*.json" // Don't try and check JSON files "**/*.spec.ts" Migrating Flow to TS syntax and .js to .ts/x Thankfully some work has been done in the open source community to aid in the conversion from Flow to TypeScript syntax, and the projects have support for many of the common language features. However, I cannot say that these projects tend to be very well maintained or mainstream. There are two dominant solutions available, and . We tried the flow-to-typescript library first but abandoned it because it crashed on any file containing a function ( ). flow-to-typescript babel-plugin-flow-to-typescript WTF? Thankfully the babel-plugin-flow-to-typescript worked for us. Almost. As of writing the same related to function support forced us to use . I don’t know what’s up with these tools and supporting plain old functions but whatever, it worked, I guess I should be thankful! bug a fork Convert JavaScript + Flow with a .js extension to TypeScript with .ts: yarn add global @babel/cli @babel/core babel-plugin-flow-to-typescript npx babel script.js -o script.ts --plugins=babel-plugin-flow-to-typescript find app - f -name | parallel # Convert single file # Convert all files and delete original JS after conversion # Prereq: 'brew install parallel' type '*.js' "npx babel {} -o {.}.ts && rm {}" Note: We actually used @zxbodya/babel-plugin-flow-to-typescript due to a bug in the main repo. Next, rename any files which import React at the top to use .tsx instead: find app/components -name - sh -c {} \; "*.ts" exec 'git mv "$0" "${0%.ts}.tsx"' Sanity Check: Does the app still run? Before proceeding any further, it’s worth checking at this point that the project actually runs. Because Babel is used to compile TypeScript to JavaScript, and Babel simply strips out all TypeScript related syntax, regardless of how many type errors your project has it should “Just Work.” In our case, it took less than half a day to update configurations, rename files, migrate all syntax, and get a running app again. But the work is obviously still far from over. Fixing 1000s of compilation errors In our case, the effort began with ~1800 TS compilation errors. Fixing this amount of errors is not a linear journey where one fix means your errors go down to 1799. Sometimes, making a change will result in dozens fewer errors, making you feel like a god among mortals, and sometimes it increases your overall error count leaving your confidence shaken! #1—Fixing the Implicit Any The number one thing TypeScript will complain about is an implicit any. Mostly due to differences between TS and Flow regarding type inference, one must immediately add additional annotations. Be warned: . Instead, ask don’t go simply adding a type explicitly where TypeScript complains “Why is this thing any?” reqs = get(props, , []) inProgressIds = reqs.map( req.id) activeRequests = actions .filter( inProgressIds.includes(action.id)) // Problem here const 'requests' const => req const // Error shown here => action Rather than adding a type to as the error suggests, is missing a type, producing the error below. The root cause could be another issue in the function, or even an entirely different file! action reqs #2—Updating React components Easily the least enjoyable and most “hairy” part of the conversion is migrating React code. Errors thrown in React code often have long error chains, sometimes with details that seem at the surface totally unrelated to the required fix. Our project limits the use of React Native primitives from our “smart” components, choosing instead to create our own set of primitives in a reusable UI framework. Button RNButton type PropTypes = {|
    onPress: mixed, : boolean,
|} Button = <RNButton {...props } /> /* @flow */ import as from 'react-native' // Seal to avoid warning about inexact spread => () custom // Trivialized component const ( ) => props: PropTypes Under Flow, one must add every prop passed into to , where instead we’d prefer to take all the props that does and add in our own custom one. <Button> PropTypes <RNButton> Button RNButton, { ButtonProps } interface PropTypes extends ButtonProps { : boolean,
} Button = <RNButton {...props } /> // Import props available for every React Native component!  :D import as from 'react-native' custom const ( ) => props: PropTypes Much preferable (and accurate)! Interfaces are one of the best parts about TypeScript! #3—Refactoring HOCs One benefit gained with TypeScript over Flow is the ability to use generic type arguments inside the body of your function. Not sure how advisable generally this is, but it’s a great feature to have when adding types for higher order components! withAThing = <T>) => 
    (WrappedComponent: React.ComponentType<T>) => 
        (props: T) => <WrappedComponent {...props } /> // TS allows the use of generics in the body of your HOC.  Yes! const (config: Config < > T However, in order to leverage this feature, we more-or-less needed to completely rewrite our type definitions for all of our higher order components. Ouch. Needless to say we‘d prefer hooks! After: 96% TypeScript Coverage $ -coverage -p tsconfig.json 68712 / 71471 96.13%
$ time tsc
tsc  29.82s user 1.76s system 166% cpu 18.955 total type # ignored tests + storybook Coverage increase of ~12%. Execution time more or less identical. By far the most significant type coverage gaps exist in our Redux Saga code. This was true under Flow as well, but it seems switching to TypeScript hasn’t improved matters much, if any. Summary If you’re still using Flow with React Native, it’s never been easier to switch! It took the equivalent of 3 engineers working 10 full working days to accomplish the conversion, including time taken for regression testing, code review, refactoring, and developing new usage patterns. The majority of errors can be easily solved with a google search for the error message, while a few required time, consideration, and experience to be confident in the fix. Though we discovered a few bugs (mostly related to incorrect third party API usage), this was a minor benefit to the effort. Gaining some additional coverage on our React code did allow for some dead code elimination. Overall, we achieved a codebase better poised for ongoing future development both in community support and developer experience.

Migrating a 50K SLOC Flow + React Native app to TypeScript

Kanban/Flow — The Scrum Master’s Not-So-Secret Weapon By: , Professional Scrum Trainer, Yuval Yeret Scrum.org We’ve all seen it. The Scrum Team that goes through the motions, implements all the mechanics of Scrum, and still when we look at what’s going on it doesn’t feel right. fondly named it Believably Bad Scrum. I call it . Barry and Christian call it . There are many names for this because every experienced Scrum practitioner has seen it way too often. Steve Porter Scrum Theater Zombie Scrum If you’re a Scrum Master I’m sure you’ve seen it as well. The Sprint Burndown Chart that looks awesome but somehow there’s still a lot of work dumped on testing towards the end of the Sprint and a scramble to try and get a Done Increment before the Sprint Review. Some years ago (circa 2007) I found a secret weapon for fighting this sort of behavior. I’m of course talking about Kanban and Flow. At the time many agile practitioners were either using Kanban to deal with contexts where they struggled to implement Scrum (think reactive maintenance/support/service/escalation teams) or replacing Scrum with Kanban. Much of my work with Kanban was focused on helping Scrum practitioners and especially Scrum Masters use Kanban to fight their believably bad Scrum not to get rid of Scrum altogether. The Scrum Masters I worked with learned about my perspective towards burndown charts (I hate them). They used Kanban boards instead. For looking beyond a single Sprint they started to show their teams Cumulative Flow Diagrams (CFDs) to drive discussions about flow, bottlenecks, and WIP. They started to complement metrics like Velocity with Cycle Time and Work in Process (WIP). Some of them organically started to look for aging WIP in their Daily Scrums. Some of them I had to point the right way. I started working with some of the Agile/Kanban tool vendors to provide more of these flow-oriented views and metrics that would help these Scrum Masters that wanted to focus on flow. When I joined Retrospectives and Community of Practice discussions I was encouraged to hear less discussions about estimation accuracy, what to do with items that weren’t finished in the Sprint and where/how to track them, and how to encourage Dev Team members to track remaining effort in JIRA. They were spending less time on the mechanics, which freed their time and spirit to care more about the bigger picture — Empiricism, Self-organization, actual improvement. They were becoming less of the classical mechanical project manager and more of a coach. They were becoming masters of Scrum. These days it’s not a secret anymore. A well-rounded professional Scrum Master needs to be a . They need to master empiricism as well as flow. Scrum as well as Kanban. Not so they could choose between them but so they’ll be able to help their teams benefit from both at the same time. servant leader and a coach Growing your Flow and Kanban competencies are recommended steps in Scrum.org’s Scrum Master learning journey. The for example is a must-read for any self-respecting Scrum Master. I would start there. (And of course the is a great experiential workshop that is aimed at Scrum Masters and Practitioners exploring this topic) Kanban Guide for Scrum Teams Professional Scrum with Kanban Originally published at https://www.scrum.org .

Kanban/Flow — The Scrum Master’s Not-So-Secret Weapon

Exploring type safety in Redux using Flow Type safety in code has 3 components: redux Actions Action creators Reducer are just . They are created by action creators. Actions plain old JS objects are functions that create action objects. Action creators are functions that take 2 arguments — and . Amongst the two, adding proper type to is a real challenge. We’ll see in a moment why that is the case. Reducers state action action Our Workbench To get my points across, I’ll use a simple reducer function throughout this article. It stores a string message from an input with the default value of “Hello World”. The user can the input, or it. clear update reset const = 'CLEAR';const = 'RESET';const = 'UPDATE'; CLEAR RESET UPDATE function (state: string = '', action) {switch (action.type) {case :return ''; reducer CLEAR case **RESET**:  
  return action.text;

case **UPDATE**:  
  return action.text;

**default**:  
  return state; }} function () {return { type: CLEAR };} clear function () {return { type: RESET, text: 'Hello World' };} reset function (text: string) {return { type: UPDATE, text };} update Manual types The “big idea” is that each action creator creates an of a unique shape — a property with value of type . action type string We can manually add types to the action objects and use them in the reducer as a type. union type = { type: 'CLEAR' };type = { type: 'RESET', text: 'Hello World' };type = { type: 'UPDATE', text: string }; ClearAction ResetAction UpdateAction type =| ClearAction| ResetAction| UpdateAction; Action function reducer(state: string = '', action: ) {...} Action This simple approach and you can see it . An added benefit of annotating code this way is that we can also add types to the action creators as well (see ). just works here here ... function (): {return { type: CLEAR };} clear ClearAction function (): {return { type: RESET, text: 'Hello World' };} reset ResetAction function (text: string): {return { type: UPDATE, text };} update UpdateAction Inferred comment types In a small, simple project, this works just fine. But when you have multiple reducers and each reducer has multiple actions where each action object is a different shape, writing everything manually becomes an challenge in itself. We need a better system; one that has some degree of . automation Let’s take a look at : ResetAction type ResetAction = ; { type: 'RESET', text: 'Hello World' } It is of the same shape as the return value of the action creator. reset() function reset() {return ;} { type: RESET, text: 'Hello World' } Instead of writing each action object type manually, we can: invoke the action creators convert the returned object into a static type use those type values in the type. Action Luckily, we don’t really have to invoke the action creators. We can leverage that will execute code blocks at “compile time” and not runtime (see ). literally Flow’s comment types here /*::// execution codeconst = clear();const = reset();const = update('');*/ "compile time" clearAction resetAction updateAction type = typeof clearAction;type = typeof resetAction;type = typeof updateAction; ClearAction ResetAction UpdateAction type =| ClearAction| ResetAction| UpdateAction; Action function reducer(state: string = '', action: ) {...} Action Unfortunately, since we’re inferring types for action objects by invoking their action creators, we annotate the creators with the inferred types. It kind of makes sense since that would create a circular chain of dependence between the inferred types and the type annotations. cannot line:5_, we pass an empty string to_ Note: In _update()_ because it requires a string argument and Flow requires that we pass all arguments for proper function calls. Extracting return type One of the most looking solutions came from . One of the comments there directed me to by and then back to the thread. legit this github thread this article Shane Osbourne The article talks about a type that “extracts” a function’s return type and using it on the action creators. A in the thread distilled the idea behind this down to its essence: . To extract the return type of a function, we use a . later comment actions are the return type of action creators; not the other way round generic function type ReturnType type = <T>((...Array<any>) => T) => T;type <Fn> =  $Call<ReturnTypeHelper, Fn>; ReturnTypeHelper **ReturnType** This works the same as the previous one (see ) and also cannot add types to action creators. But look on the bright side — less syntax! here Make the $Call Now that we have a better understanding of the process required for adding types, we can further reduce the syntax by directly calling functions by using Flow’s (you already saw it in action above). utility type [$Call](https://flow.org/en/docs/types/utilities/#toc-call) is a type that represents the result of calling the given . This is analogous to calling a function at runtime, but at the ; this means that function type calls happens statically, i.e. not at runtime. $Call<F> function type F type level This is what we get (see ). here type = <typeof clear>;type = <typeof reset>;type = <typeof update, string>; // arguments ClearAction $Call ResetAction $Call UpdateAction $Call type =| ClearAction| ResetAction| UpdateAction; Action function reducer(state: string = '', action: ) {...} Action Note: As per my experience, _$Call_ has a tendency to just “not work” at times. I am yet to experiment with it to figure out the cause behind this. If you know something, do tell me. Final verdict In the end, it all comes down to your choice. If you want to have explicit types for action creators, you need to manually add type annotations. If not, use inferred types to ease up the process and reduce syntax. I hope you find this useful in the long run. If you type your redux code in a different, possibly way, let me know in the comments section. cool

Stories, News & Mentions about FLOW

Flow’s Stories on HackerNoon