Non-React FCL Usage: dapp example

[srinjoyc]

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

While using FCL is possible in non-react example, we do not have many examples in the community of this usage. There are some issues with installing the FCL package directly due to packages used to support GRPC. This issue is to have teams work on examples that demonstrate usage of FCL in a full-stack example dapp in similar complexity to our other popular community example, Kitty Items and CryptoDappy.

Valid front-end frameworks are:

• Vue
• Angular
• Svelte
• We will consider other frameworks proposed.

Experience Required

• Experienced in JavaScript and the framework proposed.
• High level understanding of Flow's architecture (block production, transaction states, etc.)
• Good understanding of design principles and UI/UX

Minimum Feature Set (Acceptance Criteria)

Appropriate usage of all FCL APIs

• The example dApp demonstrate the latest and best usage of the most common FCL APIs via features in the dapp
• FCL discovery and non-custodial wallet features are used

Effective use of state management

• Demonstrate the best way to manage state while interacting with FCL in your chosen framework.

Well Documented & Optimized for Learning

• Features in the dApp are intended to demonstrate common patterns or use cases for dApp developers to use and learn
• Code is easy to read, semantic to the framework, and reflective of best practices
• Feature set of the dApp is comparable to the examples listed in the description.

Extension (Optional) Feature Set

Usage of other community tools

• Integrate additional tooling or services in the Flow Ecosystem into your dApp.
  • Examples include: Wallet API, Graffle, Moonpay, etc.

Milestone Requirements

1. A full stack dApp that can demonstrate FCL usage with clear documentation and usage patterns that meet the above requirements.

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way that can be extended with new functionality and clear enough for open-source developers to contribute to.

Testing

• All core logic should have unit tests.
• Each feature implemented should be tested by an end-to-end (E2E) test.

Other Requirements

Documentation

• The following pieces of documentation need to be completed alongside the code for a successful submission:
  • Installation Guide: How to get this application up and running.
  • Usage Guide: A highlight of all the features available and how to use them.
  • Contribution Guide: A thorough explanation of the codebase, where features are located, a diagram explaining complex interactions, etc. This is intended to be a primer for new contributors that would like to add or modify features.
  • Deployment Guide: How to run your demo dapp in a production environment.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• How effectively does the tool help developers coming from the framework chosen onboard onto Flow and demonstrate FCL usage?

Resources

• General Resource Guide

[10thfloor]

Hello there.
Mackenzie here. 🏄🏼‍♂️ I'm part of the Developer Experience team at Flow. Glad you're checking out this issue.
I can help answer any questions you might have about what you see here, and if you decide to take this on, I'll be your primary point of contact for you or your team.

Please add your comments/questions here, or find me on the Flow Discord (mack)

Happy hacking!
🚀

[amitkothari]

Hi @10thfloor, I would like to work on this issue and build a dapp example using Svelte. Here is the team's Hacker Earth profile - https://www.hackerearth.com/challenges/hackathon/flip-fest/dashboard/3dca8c7/team/ 😄

[10thfloor]

Excellent! Do you have an idea for what functionality you might want to include?

[amitkothari]

I am thinking of building a demo app, similar to the other community examples, that will demonstrate how to deploy contracts, integrate wallets, and mint NFTs.

I have few initial ideas, will finalize and post more details soon :)

[10thfloor]

Great. FYI, FCL is not compatible out-of-the-box with svelte-kit.

Take a look at this project for an example of how to start with Svelte and FCL:
https://codesandbox.io/s/fcl-svelte-wc3wb?file=/Hello.svelte.

The thing to notice here is the use of Rollup, and Rollup plugins required to work with FCL.

[amitkothari]

Thanks a lot, I had some issue with Rollup but got Svelte and FCL working with webpack. I will follow this example and get the demo working with Rollup :)

[10thfloor]

@amitkothari Actually, I'd suggest sticking with Webpack.

Some others are exploring Svelte as well, and were not able to make the Codesandbox example work without replacing Rollup with Webpack.

[amitkothari]

Thanks @10thfloor , I will continue with webpack then.

I am working on a demo similar to crypto dappy with similar smart contract, authentication, scripts & transactions to interaction with flow blockchain. I will try and get the basic app working soon.

[ic3guy]

I'm looking into getting an Angular 12 example up and running. I've built off of onflow/fcl-js#506 and I think I've nailed down the issues regarding buffer/process/http/https using a custom webpack config to implement the node polyfills rather than manually doing it in the polyfills.ts file.

[amitkothari]

@ic3guy I am also using custom webpack config for Svelte demo app.

[ic3guy]

This is what I needed to use in Angular 12 / Webpack 5.

Angular used to provide built-in polyfills, Webpack 4 did as well for node core calls. Here we are telling webpack that we actually do need these node specific polyfills.

While the Angular team says that anything running in an Angular app shouldn't rely on node specific calls, we have no choice due to the third party dependencies that rely on some node specific stuff. The stream-http and https-browserify to me seem to be ok to use in the browser, even if it isn't canonical Angular use.

In a custom-webpack.config.ts file:

const webpack = require('webpack')

module.exports = { 
    plugins: [
        new webpack.ProvidePlugin({
            Buffer: ['buffer', 'Buffer'],
            process: 'process/browser'
        })],
    resolve: { 
        fallback: { 
            "http": require.resolve('stream-http'),
            "https": require.resolve('https-browserify'),
            "buffer": require.resolve('buffer'),
            "process": require.resolve('process/browser')
        } 
    }
}

along with a global window polyfill in polyfills.ts

(window as any).global = window;

To use a custom webpack config one must

npm install stream-http https-browserify buffer process @angular-builders/custom-webpack

In angular.json

"architect": {
        "build": {
         \\"builder": "@angular-devkit/build-angular:browser", 
         "builder": "@angular-builders/custom-webpack:browser"
         ...
          "options": {
          ...
            "customWebpackConfig": {
              "path": "./custom-webpack.config.ts"
            },
            "allowedCommonJsDependencies": [
              "buffer",
              "@improbable-eng/grpc-web-node-http-transport"
            ]
          }
...
 "serve": {
        // "builder": "@angular-devkit/build-angular:dev-server",
            "builder": "@angular-builders/custom-webpack:dev-server",

The allowedCommonJsDependencies is telling angular that we know what we are doing. Again it would be great if those third party dependencies didn't use CommonJS but we are a little stuck here. The Angular docs claim that bundle sizes could be larger, but for a proof of concept, I'm ok with doing this.