DEV Community: Abdou Ouahib

Fullstack Ethereum Development Course

Abdou Ouahib — Mon, 14 Mar 2022 10:09:09 +0000

TLDR: Check out this playlist to learn how to build a Full-stack Ethereum dApp.

Hi everyone👋

Web3/blockchain is one of the hottest topics right now, and a lot of developers want to get into this field. So if you're one of them, then keep reading.

I made a YouTube series where I build NFT Marketplace from scratch, and here are the steps I followed (what you will learn):

Write the Ethereum smart contract using Solidity.
Write integration tests for the smart contract, with the help of Hardhat.
Deploy the smart contract to Rinkeby using Hardhat.
Create and deploy a subgraph (The Graph protocol) to index the smart contract.
Build a front-end using Next.js and Tailwindcss:
- Use ethers.js to send Ethereum transactions (Create NFT, list NFT for sale, cancel NFT sale, buy NFT).
- Use Apollo to query the subgraph GraphQL API endpoint and fetch NFT data.

The Tech Stack:

Solidity for writing the smart contract.
Hardhat as the Ethereum Development Environment.
Typescript, Next.js and Tailwindcss for the front-end.
Ethers.js for interacting with the blockchain from the front-end.
The Graph protocol for indexing the smart contract.
Apollo, both for querying the GraphQL endpoint, and as a CLI to generate Typescript interfaces for our queries.

The videos are heavily technical (lots of code), but I still explain everything I do, in detail.

Check out this playlist to start learning.
Here is the project repo.
And here's a hosted version of the dApp.

Happy coding!😇

I built a chat app using React and GraphQL

Abdou Ouahib — Wed, 28 Apr 2021 16:12:24 +0000

TLDR

You can try the app here: chat.abdou.dev

You can view the source code in this github repo

Intro

About 4 months ago, I decided to start learning web development, and I thought that the best way to know that I became a job-ready developer, is to build a complex, real-world application, from scratch. My first choice was to build a chat app. It seemed complex enough for me, and I knew I would learn many things along the way.

Disclaimer

I think it's only fair to say that, although I had no experience in web dev, I wasn't a complete newbie to the coding world. I did some C programming, I worked with Flutter a little, and I think it made it a lot easier for me to pick up all those new technologies like React. Otherwise, this would have taken me a lot more than 4 months :). Also, here's my GitHub graph in the aftermath.

The first steps

I knew that I had to learn the basics. It doesn't make sense to start learning the crazy stuff (React) first, before having a solid (meh) understanding of HTML, CSS, and Javascript (SPOILERS: I ended up learning Typescript instead).

So, my first destination was FreeCodeCamp. It had a big nice curriculum of everything you need to get you started in web dev. I finished the first 3 certifications, and by then, I was ready to go out into the wilderness, and start learning on my own.

Building the app

Now that I had all the basics I needed, it was time to start building the chat app.

The tech stack

I took a look around some job listings here and there, to see what's popular in the market, and I finally decided to use these technologies for my next project (non-exhaustive list):

Frontend

React
Redux: I'm building a full fledged chat app after all. I will need a solid state management solution.
MaterialUI for components/styling
Apollo client for GraphQL

Backend

Node.js and Express.
Apollo server for GraphQL
TypeGraphQL: for building GraphQL APis
PostgreSQL in combination with Prisma (The next generation ORM, very cool stuff) for the database.

Did I mention that I used Typescript throughout the project? I really find it hard to work without type-safety.

Setup

At that time, I've been hearing about Next.js, and it seemed like something I'd want to learn, so I decided to use it. I was also planning to do all the coding using TDD (test driven development), so setting up a test environment was a must. After lots of headaches, I finally got jest and React Testing Library to work with Typescript. Now I'm ready to start coding.

App features

Authentication

To make things simple, I used Google for authentication. The user signs in with Google, I grab the token and send it to the backend. If no user is associated with that Google account, I create it, then proceed.

I spent some time researching different authentication methods, the simplest one was to use jwt. Other solutions like auth0 seemed very complicated. I tried to implement jwt authentication in the best way I could. I didn't use local storage to store any tokens (although it's widely used in many tutorials), and I used a refresh/access token strategy:

Refresh token: it's generated with a very long expiry date (it basically never expires), and it is set in a http-only cookie, so the client can never access it. It's used to generate new access tokens when they expire.
Access token: it's generated with a low expiration time (30min), and it's only stored in memory (in a variable) in the frontend. It is sent with all future http requests to make authenticated actions.

I also implemented auto-refreshing in the frontend, so when the access token expires, a new one is generated without the user noticing anything. Not very sophisticated, but I'm happy with the results.

User profiles

Each user has a unique username, a name, and a profile photo. These are all public, and can be viewed by anyone. The user has the ability to change his username, name, and upload new profile pictures. It's kinda worth noting that pictures are resized to different sizes (small, medium, and original). So we don't need to fetch a 1280x1024 picture for a 48x48 user avatar.

Friends

Each user can send friend requests to other users, and they can either accept or decline them, exactly like facebook. A user can also block another user, preventing them from sending further friend requests and messages. Being friends with someone makes you able to text them and view their active status (last seen date) if they don't hide it.

Notifications

For now, they only show if someone accepted your friend request. I can't think of any other use-case at the moment.

Messaging

The core feature of the app, It was the last one implemented after all the above. I tried to clone Facebook Messenger's behaviour. It wasn't that hard since I was already familiar with everything at this point, but I still faced some very annoying problems:

The delivery status: If you look at facebook messenger, you'll notice that every message has a delivery status, that can be either SENDING, SENT, RECEIVED, DELIVERED, or SEEN. Trying to implement it exactly the same way messenger did, was very tricky. I didn't think about this problem from the start, so I ended up modifying many things to get it working.
Race conditions: You usually expect things to happen in a certain order, for example, a message status can go from SENDING to SENT, and then to DELIVERED, but sometimes it's not the case. If the internet is slow for example, you can get notified that the message was delivered, before a response has reached the client to confirm that the message was sent, therefore the status goes from SENDING to DELIVERED, and then to SENT, which is not at all desired, and can lead to annoying bugs, like the message being shown twice, or not at all. Handling these race conditions was not straightforward, and I think the code became a little messy afterwards.

The user can also send multiple images/videos with each message.

Realtime

Before starting the messaging feature, I always thought I was going to use sockets to make it realtime. Then I figured that there's a chance GraphQL has a solution for this kind of problem, and I was right. GraphQL supports
Subscriptions, which are (quoting Apollo docs) "useful for notifying your client in real time about changes to back-end data, such as the creation of a new object or updates to an important field". They were perfect for this use-case, and implementing them was fairly simple.

Next.js and Vite.js

Almost halfway through the project, I realized that I'm not really benefiting from most of Next.js features (Or maybe I didn't know how to?). At the same time I discovered Vite.js that uses esbuild, which is the fastest bundler out there, so I switched to it. It was indeed really fast, I could make changes to the code and see them instantly in the browser, so I'm sticking with it for now. I'm not completely giving up on Next.js, I will definitely learn it later, while building a suitable project (A blog/portfolio for example). After all, concepts like Server Side Rendering are a little too advanced, and I'm still new to all of this.

Hosting

I used digitalocean to host both the front and the backend. I bought a droplet for 5$/month and put everything inside. Deploying was fun, I always disliked everything related to IP addresses, DNS, firewalls... but it turned out to be not that bad, everything has an article/tutorial explaining all the details, and you just have to follow.

For file hosting, you'd usually want to use some cloud storage solution, like an Amazon s3 bucket for example, but it doesn't make sense to pay for it separately, since this is just a personal project. So I decided to just use the droplet's memory instead.

The hard parts

These are the things I found difficult the most. They sometimes made me sit and consider my options of quitting the whole thing, and becoming a full time baker.

Configuration

I'm not sure what to call it, so I called it configuration, but you know... when you're trying to make jest work, but it just won't work, even though you followed all the instructions. To finally discover, by accident, in a comment buried deep inside a github conversation, that you have to remove a certain line from you tsconfig.json... Or that time when I wanted to use decorators inside a Next.js project, but it didn't work, so I had to painfully experiment with Babel config, which I know absolutely nothing of, until it started working, but then I discovered that Next.js HMR broke, so I had to give up using decorators after all that wasted time. The funny thing is, I tried to use them in the backend project, and they just worked from the first try.

I always stumble upon terms like webpack, bundlers, build tools..., but they remain foreign to me, I just use them without knowing anything about how they work, and I feel bad about it. Maybe I should start learning them seriously, maybe that will help me with those time-consuming configuration problems in the future.

Styling

Styling was one of the hardest things, I didn't know how should I style my components. Should I use plain CSS files? Should I use CSS modules instead? Should I use bootstrap or something more modern like Tailwind? It was a really hard decision to make. I used CSS modules at first, and then switched to Styled Components, to finally settle down with MaterialUI. At last, I had to migrate everything to use MaterialUI and its JSS solution. It was a real mess, the refactoring was very time-consuming, and I still think I'm not doing things as they're supposed to be done. Now I can't even add dark-mode without modifying every single component in the code base.

Virtualization

I already use pagination, if a conversation has a 1000 messages, I don't fetch them all at once. I fetch only the first 30, and when the user scrolls all the way to the top, I fetch another 30, and so on and so forth.

This is not enough, because after fetching all those 1000 messages, we will have a 1000 message elements in the DOM, and that's not good performance wise. Virtualization solves this problem by rendering only the visible elements. Let's say the user's viewport can fit 20 messages, then only 20 (usually a little more than 20) elements will be present in the DOM, and while the user scrolls, the invisible messages will be replaced by the visible ones, but the DOM will always have the same number of elements.
(The below illustration is from this tweet

Some libraries like Virtuoso and React Window are doing a nice job implementing virtualization for us, but in my case, both of them didn't work well. Message elements have variable heights, and those heights must be calculated before rendering, along with many other calculations. When the list of messages gets big, those calculations become very heavy, and the app becomes unusable. I spent so much time trying to make virtualization work, but in the end, I decided it's better to stop trying, and just render everything into the DOM. So far I haven't noticed any performance issues, and I checked Facebook Messenger and Whatsapp Web, they both don't use virtualization, it was a big relief knowing that Facebook is doing the same thing I'm doing :).

In mobile development (or at least in Flutter), you have built-in virtualization that's working out-of-the-box, and until now, I always thought that it's something standard, and you can find it in all other SDKs, I took it for granted. I'm still confused why React doesn't have such a thing, is virtualization not that important in the web?

Keeping everything tested

Since I was doing test driven development, I had to write tests for almost every piece of production code. Keeping your codebase well tested is a very important thing, there's no doubt about that, but this process becomes extremely tedious. Some tests are harder than others, and sometimes you spend 90% of the time writing mock objects for a test, and only 10% to write the actual testing, and if, god forbid, you made changes to the code you tested, you'll have to go through those tests all over again.

In the end, it's always worth it. Having a strong test suite gives you confidence that your code is actually working. Whenever you want to make a new commit, you just run those tests, and if everything passes, you're good to go.

Things I'm not proud of

Theming

I know I already complained about styling, but theming is one of the things that I didn't do correctly, and I blame myself for that. I knew that I shouldn't hardcode colors, or font sizes, or anything related to styling, inside every component. I had to use a global theme instead, and material UI provided a convenient way to do it, but sill, I was always in a rush to see the results of my work on screen, I just had to build those components as quickly as possible, telling myself that I will refactor things later, but little did I know. At one point, it became too much, and I was too lazy to refactor everything, so I just gave up and left things as they are.

Next time, I will write down my global theme first, before writing any component code.

Routing

I'm pretty sure I could've implemented routing a lot better than the way it is now. I didn't discover React Router until I had already finished the whole authentication feature. I was using conditional rendering, if the user is logged in I display the main screen, if not I display the login screen. After that, I started using React Router, and I'm still not sure if I'm fully utilizing its power, I had to use some hacky tricks to get things working as I wanted
(I needed a custom back button, that does not always act like the one in the browser), which wasn't very clean in my opinion. I'll definitely give more time and thought to routing in my next project.

App size

Lastly, the app is over 1.4 MB in size, I'm not sure, but I think it should be a lot smaller than this. I will take some time later to analyze the issue.

Final thoughts

This little journey was fun, and you can say I'm satisfied with the final result. I think I can finally call myself a "fullstack developer"? I know There are many other things in this field that I have yet to explore and get good at, but this is just the start.

I don't know where to go from here, so I'll take my time reflecting and deciding on the next steps. Otherwise, I hope you had a good read, feel free to try out the app and leave me some feedback. Bye bye!

Step up your Redux game with Typescript

Abdou Ouahib — Sun, 21 Feb 2021 18:19:40 +0000

Hi 👋
I spent some time experimenting with Redux and Typescript, and I finally got my head around it. I documented what I learned in this article, which will also serve as a tutorial on how to use Redux with Typescript, particularly in a React application.

While learning redux, I was trying to answer these questions:

How can I fully benefit from Typescript's type system?
How to properly inject dependencies into redux? (Hard dependencies are a code smell after all)
How do I test all of this?

I answered all these questions throughout this article, enjoy!

NOTE: This is not a complete beginner tutorial, if you find it difficult to follow, I advise you to take a look at Typescript Quick Start tutorial from RTK.

What we are building

We are going to build a small React app that only has an authentication feature. Meaning that you can login, view the current user, and logout. This is enough to cover most of redux important concepts. There will be no backend, only mock data. If you want, you can later replace the mocks with a real API, and the Redux part will still work perfectly.

Here's a sneak peak of the final product.

Getting started

I made a base project for your convenience, it has all the required packages, components, and services. So we can focus only on the Redux part. All you need to do is clone the github repo and install the packages:

git clone https://github.com/aouahib/redux_app_base.git
cd redux_app_base
npm install
npm start

Visit your localhost. You should see the login page.

The folder structure

Inside /src/features/auth is everything we need for our authentication feature, the only thing missing is the redux logic.

the data/ subfolder contains the authentication repository and all its dependencies. It's there where we fake API calls and return mock data.
the types/ subfolder contains types used mainly by the data layer, but also used in other places throughout the app.
the ui/ subfolder contains React components.

Feel free to explore more on your own.

The Store

Let's start by adding a store to our app. We will be using Redux Toolkit package, it's the recommended way of using Redux. Create a new file store.ts inside /src/app/ folder, and add the following code:

import {combineReducers} from "redux";
import {configureStore} from "@reduxjs/toolkit";

const rootReducer = combineReducers({
  // TODO: Add reducers
});

const createStore = () => {
  return configureStore({
    reducer: rootReducer
  })
}

export default createStore;

As you can see, we used combineReducers to create a rootReducer. And added the createStore function, that returns a store configured with our rootReducer. The rootReducer is useless for now because it's "empty", we'll add the authentication reducer to it in a moment. But first, let's add some types that will help us a lot later.

First, we need the Store and the State types. Usually, these types keep changing a lot during development, since we constantly add new reducers and modify existing ones, so it's not a good idea to write them manually, and modify them every time we make a change. That's why we have to infer them, we'll use ReturnType to do that, we give it a function type as a type parameter, and we get back that function's return type.

// A function that returns a number
const foo = () => 2;

type FooReturn = ReturnType<typeof foo>;
// the type FooReturn is number

Since rootReducer is a function that returns a State, and createStore is a function that returns a Store, we can infer our types the same way we did in the example above. Let's also get the type of the dispatch method. Add these lines to your store.ts file:

export type AppStore = ReturnType<typeof createStore>;
export type AppState = ReturnType<typeof rootReducer>;
export type AppDispatch = AppStore['dispatch'];

The Slice

It's time to write some redux logic, but first, let's define what a "Slice" is. Quoting the docs:

You may be wondering, "what is a 'slice', anyway?". A normal Redux application has a JS object at the top of its state tree, and that object is the result of calling the Redux combineReducers function to join multiple reducer functions into one larger "root reducer". We refer to one key/value section of that object as a "slice", and we use the term "slice reducer" to describe the reducer function responsible for updating that slice of the state.

Fair enough, let's create our authentication slice, add a file inside /src/features/auth/ folder, and name it auth-slice.ts. We need to define the type of the auth state, and while we're at it, let's also define the initial state, add this code to the file:

import User from "./types/user";
import AuthError from "./types/auth-error";

export type AuthState = {
  currentUser: User | null,
  loading: boolean,
  error: AuthError | null,
};

const initialState: AuthState = {
  currentUser: null,
  loading: false,
  error: null,
};

currentUser: is an object of type User if a user is logged in, otherwise it's null.
loading: true if the user is currently logging in, we'll use it to display some kind of spinner.
error: is the error that happened in the latest operation, or null if none happened.

Pretty simple, now let's create the actual slice:

...
import {createSlice} from "@reduxjs/toolkit";

...

const authSlice = createSlice({
  name: 'auth',
  reducers: {},
  initialState,
});

We named it 'auth', we gave it the initialState, and an empty reducers object. reducers will stay empty, because we're not interested in plain reducers, since they only change the state, and have no side effects. We can't put any data fetching logic inside a plain redux reducer. Instead, we need to use Middlewares.

The middleware we'll be using is redux-thunk, it lets you write plain functions that contain async code, and dispatch them to the store. Since we used RTK's configureStore, the thunk middleware is automatically set up for us by default.

Async Thunks

We'll make use of the handy createAsyncThunk from RTK to create our first async thunk, which will be responsible for logging the user in. Add this code to the auth-slice.ts file:

...
// Add createAsyncThunk to the existing import
import {createAsyncThunk, createSlice} from "@reduxjs/toolkit";

...

const loginWithEmailAndPass = createAsyncThunk(
  'auth/loginWithEmailAndPass',
  async () => {
    // TODO: login 
  }
)

As you can see, createAsyncThunk expects 2 arguments:

A name: auth/loginWithEmailAndPass
A function: where we can put our async logic

This thunk does nothing for now, in order to make it useful, we need to know how we're going to use it, here's the scenario:

The user enters his email/pass and clicks the login button
we dispatch signInWithEmailAndPassword async thunk, passing the email and pass as argument.
The async function we passed to createAsyncThunk gets the email/pass, and makes an API call to log the user in.
- If the login succeeds, the async function should return a User. The thunk middleware will dispatch an action of type loginWithEmailAndPass.fulfilled, with that user as a payload.
- If the login fails, the async function should return an AuthError as a rejected value. the thunk middleware will dispatch an action of type loginWithEmailAndPass.rejected, with that error as a payload.

Since we want to make use of Typescript's type system, we need to add some type parameters. createAsyncThunk accepts 3 type arguments, ordered as follows:

The return type of the async function
The type of the argument passed to the async function
The thunk API type: it specifies the store's state type, its dispatch type, and the type of the reject value of the thunk being created (Along with other types) (This may be confusing at first but you'll understand it in a moment).

Let's start by specifying the type of our thunk API. We don't need to access the dispatch nor the state from our thunk, so we don't care about their types. We only need to specify the type of the rejected value, so our thunk API type will be like this:

type ThunkApi = {
  rejectValue: AuthError
};

Now let's add types to our createAsyncThunk function:

...
import {EmailPass} from "./types/email-pass";

...

const loginWithEmailAndPass = createAsyncThunk<User, EmailPass, ThunkApi>(
  'auth/loginWithEmailAndPass',
  async () => {
    // TODO: login 
  }
)

Now you'll notice a compile time error, since we must return Promise<User | RejectValue<AuthError>>, our thunk is typed 😉.

Dependency injection

Before we continue, there's something we have to take care of. We will be using AuthRepository (located at /src/features/auth/data/) to make API calls. We need to access it from our async thunk. We can do this in different ways: we can use a global variable (❌ not clean), we can pass it as an argument to our async thunk (❌ not that clean too), or we can inject it once into our thunk middleware when creating the store, and have access to it inside all our async thunks, which will also make testing cleaner (✅ clean). Let's do it.

First, let's instantiate an AuthRepository. Usually, it's better to put all dependencies like this inside a single file, or use some kind of container to store them. Since we don't have that many dependencies, I'm not going to use a container.

Inside the /src/app/ folder, create a file dependencies.ts, and copy the following code:

import {FakeAuthApi, IAuthApi} from "../features/auth/data/services/auth-api";
import {ILocalStorage, LocalStorage} from "../features/auth/data/services/local-storage";
import IAuthRepository, {AuthRepository} from "../features/auth/data/auth-repository";

// Instantiate an auth repository with its dependencies
const authApi : IAuthApi = new FakeAuthApi();
const localStorage : ILocalStorage = new LocalStorage();
const authRepo : IAuthRepository = new AuthRepository(authApi, localStorage);

// the object that will be injected into the store as extra arg
const storeExtraArg = {
  authRepo,
}
// also export the type of the above object for convenience
export type StoreExtraArg = typeof storeExtraArg;

Nothing complicated. If you want some inspiration on how to instantiate multiple dependencies, you can take a look at this code. Otherwise, let's actually inject this into the store, go to /src/app/store.ts, and modify your createStore function:

// Add getDefaultMiddleware to the existing import
import {configureStore, getDefaultMiddleware} from "@reduxjs/toolkit";
import {StoreExtraArg} from "./dependencies";

...

// Add a parameter of type StoreExtraArg
const createStore = (extraArg: StoreExtraArg) => {
  return configureStore({
    reducer: rootReducer,
    middleware: getDefaultMiddleware({
      // Pass that parameter as a thunk extra argument
      thunk: {extraArgument: extraArg},
    }),
  });
};

Now extraArg is available in all our async thunks, we just need to do one last tweak. Remember our ThunkApi type we wrote earlier, we'll add one more type to it, go back to auth-slice.ts and add the extra type:

...
import {StoreExtraArg} from "../../app/dependencies";

...

type ThunkApi = {
  rejectValue: AuthError,
  extra: StoreExtraArg,
};

Let's also make our thunk's async function take the parameters we specified:

const loginWithEmailAndPass = createAsyncThunk<User, EmailPass, ThunkApi>(
  'auth/loginWithEmailAndPass',
- async () => {
+ async (emailPass, thunkAPI) => {
    // TODO: login
  }
);

And now our async thunk is fully typed, if your IDE has autocompletion, you can see that authRepo is there inside the thunkAPI:

Last but not least, let's use authRepo to sign the user in, here's the final version of loginWithEmailAndPass:

import {isRight} from "fp-ts/Either";

...

const loginWithEmailAndPass = createAsyncThunk<User, EmailPass, ThunkApi>(
  'auth/loginWithEmailAndPass',
  async (emailPass, thunkAPI) => {
    // Make the api call
    const result = await thunkAPI.extra.authRepo.signInWithEmailAndPassword(emailPass);
    // If the login succeeds, return the User
    if (isRight(result)) {
      return result.right;
    }
    // If the login fails, reject with the AuthError
    return thunkAPI.rejectWithValue(result.left);
  }
);

You may be confused about isRight, but it's really simple. The authRepo returns Promise<Either<AuthError, User>>. The Either type can either be Left or Right. If it's Left, we know that it's an AuthError, else it's a User. We're doing this because we want to catch all exceptions in the repository, and then return regular objects. It's better than writing try...catch blocks everywhere. If you want to learn more about the Repository pattern, you can check my article here.

Reducers

As you may recall from earlier, the thunk middleware will dispatch actions depending on the return value of the underlying async function. We didn't write any code that will handle these actions, let's do that now. Add the extraReducers to the authSlice as follows:

const authSlice = createSlice({
  name: 'auth',
  reducers: {},
  initialState,
  extraReducers: builder => {
    builder
      .addCase(loginWithEmailAndPass.pending, state => {
        // Login started
        state.loading = true;
        state.error = null;
      })
      .addCase(loginWithEmailAndPass.fulfilled, (state, action) => {
        // Login succeeded
        state.currentUser = action.payload;
        state.loading = false;
      })
      .addCase(loginWithEmailAndPass.rejected, (state, action) => {
        // Login failed
        if (action.payload == undefined)
          state.error = AuthError.general;
        else
          state.error = action.payload;
        state.loading = false;
      });
  }
});

We just added extra reducers to handle actions coming from loginWithEmailAndPass async thunk:

The pending case: The API call is being made, we reset the previous error, and set loading to true.
The fulfilled case: The API call was successful, and we got our user object. Save that user in the state and reset loading back to false.
The rejected case: Some error happened while making the API call, save that error in the state, and reset loading back to false.

We used the builder syntax to make our reducers typed. If we used a simple object as the value for extraReducers, the state and action objects inside the reducer functions won't be typed.

Let's export the async thunk, as well as the main authentication reducer.

export const authActions = {loginWithEmailAndPass};
export default authSlice.reducer;

And finally, let's add the exported reducer to the store, go to /src/app/store.ts, and add it:

...
import authReducer from "../features/auth/auth-slice";

const rootReducer = combineReducers({
  auth: authReducer, 
});
...

Hooking redux to the components

We will use a provider on the top of the component tree to make the redux store accessible to all components. The components also need access to actions so they can dispatch them to the store, so we will provide them too using the Context API.

Custom redux hooks

react-redux library has some useful hooks to access the Redux API. Namely useDispatch and useSelector. These hooks are not typed, we could import AppState and AppDispatch and make them typed, but since we'll be doing it inside many components, it's better to create custom typed versions of these hooks, and use them instead. Create a file under /src/app/ and call it redux-hooks.ts, and add the following hooks to it:

import {TypedUseSelectorHook, useDispatch, useSelector} from "react-redux";
import {AppDispatch, AppState} from "./store";

export const useAppDispatch = () => useDispatch<AppDispatch>();

export const useAppSelector: TypedUseSelectorHook<AppState> = useSelector;

Auth actions

Create a file under /src/auth/ called auth-actions-context.tsx, and copy the following code:

import React, {useContext} from "react";
import {authActions} from "./auth-slice";

export const AuthActionsContext = React.createContext(authActions);

export const useAuthActions = () => useContext(AuthActionsContext);

const AuthActionsProvider = ({children}: { children: React.ReactNode }) => {
  return (
    <AuthActionsContext.Provider value={authActions}>
      {children}
    </AuthActionsContext.Provider>
  );
};

export default AuthActionsProvider;

We'll be using useAuthActions hook instead of using useContext and AuthActionsContext every time. The AuthActionsProvider is there for the same purpose.

The store

Let's instantiate a store, go to /src/app/dependencies.ts and add the following code:

import createStore from "./store";
...

export const store = createStore(storeExtraArg);

Providing

Go to /src/index.tsx, and provide the store/actions:

...
import {Provider} from "react-redux";
import AuthActionsProvider from "./features/auth/auth-actions-context";
import {store} from "./app/dependencies";

ReactDOM.render(
  <Provider store={store}>
    <AuthActionsProvider>
      <MuiThemeProvider theme={theme}>
        <App/>
      </MuiThemeProvider>
    </AuthActionsProvider>
  </Provider>,
  document.getElementById('root')
);

Hooking the App component

Head to /src/app/app.tsx, you'll notice we are using a user variable which is always null, and we use it to conditionally render LoginPage/LoggedInPage. We need to use the store's state to decide which page to render.

We'll be using the useAppSelector hook to access the state of the store we provided earlier, modify app.tsx as follows:

...
import {useAppSelector} from "./redux-hooks";

const App = () => {
  const user = useAppSelector(state => state.auth.currentUser);

  return user != null ? <LoggedInPage/> : <LoginPage/>;
};

export default App;

To make sure everything works, run npm start. You should still see the login page, because the user is initially null.

The Login page

Head to /src/features/auth/ui/login-page.tsx, it has many lines of code as you can see, but we're only interested in the loginClicked callback. It's fired when the user clicks the login button. For now, it only validates the email and password, then returns. Instead of just returning, let's actually log the user in.

First, let's grab the dispatch method, and our loginWithEmailAndPass action. Import useAppDispatch and useAuthActions, then add the following lines to the top of the component:

const {loginWithEmailAndPass} = useAuthActions();
const dispatch = useAppDispatch();

Then, inside the loginClicked function, dispatch loginWithEmailAndPass action to the redux store:

const loginClicked = useCallback((e: React.MouseEvent | React.FormEvent) => {
  e.preventDefault();
  if (validate()) {
    dispatch(loginWithEmailAndPass({email, password}));
  }
}, [dispatch, validate, loginWithEmailAndPass, email, password]);

Also, remove the hardcoded loading and error variables, and replace them with the ones existing in the auth state. Import useAppSelector, and grab the state variables:

const {loading, error} = useAppSelector(state => {
  return {loading: state.auth.loading, error: state.auth.error};
});

That's it, refresh the page, enter an email and a password, click login, and BOOM, they're incorrect 🤣. Use the following credentials to login:

Email: escanor@gmail.com
Pass: password

Everything is working as expected, the progress indicator shows while the API is being called, an error snackbar appears if the login failed, and the LoggedInPage is shown if the login succeeds.

The LoggedIn page

Go to the LoggedInPage at /src/features/auth/ui/logged-in-page.tsx.

First of all, You'll notice that we're using a hardcoded user, let's replace it with the user in the auth state. Import useAppSelector and shallowEqual, remove the hardcoded user constant, and grab the actual user:

const user = useAppSelector(state => state.auth.currentUser, shallowEqual);

You will get a compile time error saying that user can be null. This is normal since it's of type User | null. But we are sure that user is never null if the LoggedInPage is being displayed (Remember the conditional render in app.tsx?). So it's safe to just throw an error if this ever happens:

const LoggedInPage = () => {
  const user = useAppSelector(state => state.auth.currentUser, shallowEqual);

  ...

  if (user == null) {
    // This should never happen
    throw new Error('Displaying the LoggedInPage without a logged in user');
  }

  return (...
};

Now login, and everything should work as expected.

Second of all, the logout button doesn't do anything. Let's change that.

Logging out

In the same way I implemented loginWithEmailAndPass async thunk, I'll also implement logout. Here's the final auth-slice.ts:

In the LoggedInPage, import useAuthActions and useAppDispatch, and dispatch the logout action when the logout button is clicked:

const dispatch = useAppDispatch();
const {logout} = useAuthActions();

const logoutClicked = useCallback(() => {
  dispatch(logout());
}, [dispatch, logout]);

Here's the final LoggedInPage:

Now login, click the logout button, and you should be logged out.

Testing

I promised that everything will be tested, but this article is already long enough. So, I'll leave testing to the next one, and will link it here once it's done.

Homework

It will be nice if the user can stay logged in after closing or refreshing the page, which is currently unsupported. Try to add this functionality to the app. You only have to add redux + component logic, the persisting is already done for you. You can just call authRepo.getCurrentUser(), and it will return a User | null depending on whether the user is logged in or not. Good luck!

Conclusion

This was a long tutorial, I hope it wasn't that confusing, and you actually learned something from it 😅. Let's recap all we've done so far:

We created an authentication Slice that contains everything related to the authentication state of our app.
We wrote Async Thunks that manipulate the state asynchronously.
We injected dependencies to the Store, so we can access them in all our Async Thunks.
We made sure to fully benefit from the type system.
No hard dependencies, everything is injected/provided.

You can find the final code in this GitHub Repo.

I hope you had a good read, see you in the next 👋.

The Repository pattern with Typescript

Abdou Ouahib — Mon, 15 Feb 2021 20:47:25 +0000

Hi 👋
In this article, I'm going to talk about the Repository pattern, and show you how I implemented a Repository to handle authentication, for the app I'm currently working on, in a way that made it very easy for me to write tests for it. Then I'll show you how to write those tests. I will also briefly go through other topics such as dependency injection, abstraction...etc.

The Repository

If you don't know what a Repository is, here's a fancy definition:

Repositories are classes or components that encapsulate the logic required to access data sources. They centralize common data access functionality, providing better maintainability and decoupling the infrastructure or technology used to access databases from the domain model layer.

Now I'll try to give a more human readable version, and I'll use our authentication feature as an example.
I want users to be able to use Google to sign in to my app, the flow would be something like this:

The user signs in with google.
We retrieve the token returned from google, and send it to the backend.
The backend sends an access token back, which we can use for all future requests.
We persist the token locally, to keep the user signed in.

From this, we can see that we need 3 data sources:

GoogleAuth
AuthApi: that communicates with the backend
LocalStorage: where we persist the logged in user

And then we'll have an AuthRepository that internally uses these 3 data sources, and exposes a simple API that we can use to handle authentication. We'll see how to implement this in a moment, but this is how a repository works in my simple point of view.

Abstraction is your friend

The AuthRepository is a very good example of abstraction. It hides implementation details from all other parties that use it. For example, a react component can use this repository, and sign the user in by just calling authRepo.signInWithGoogle(). The component doesn't care or know how the sign in is done, it doesn't know that we use 3 data sources to do the work. This abstraction is very useful, for instance, if we want to test the component, we can just mock the repository, and verify that signInWithGoogle has been called. We will be sure that the sign in will work, because we would have already written tests for AuthRepository. Let's write this abstraction:

interface IAuthRepository {
  signInWithGoogle(): Promise<User>;
}

NOTE1: The 'I' in 'IAuthRepository' stands for Interface (duh), and It's just a naming convention.

NOTE2: There should be more function declarations in the interface, like signOut() ...etc, but I wrote only one for sake of simplicity.

And just how the repository abstracts the implementation details, the data sources also should do the same thing. Let's wite their interfaces too:

interface IGoogleAuth {
    // returns a token
    signIn(): Promise<string>
}

interface IAuthApi {
  signInWihGoogle(token: string): Promise<User>;
}

interface ILocalStorage {
    write(key: string, value: string): Promise<null>;
    read(key: string): Promise<string | null>;
}

You can define the User type any way you want. To keep it simple, I'll just use the following:

type User = {
    accessToken: string
}

Now we have everything we need to start implementing the AuthRepository

Implementations

We will create a class that implements IAuthRepository, and give concrete implementations for all its function declarations (in this case we only have one)

class AuthRepository implements IAuthRepository {
    signInWithGoogle(): Promise<User> {
        throw new Error("Method not implemented.");
    }
}

We need access to our data sources inside the class, so let's make it depend on them.

class AuthRepository implements IAuthRepository {
    private _authApi: IAuthApi;
    private _googleAuth: IGoogleAuth;
    private _localStorage: ILocalStorage;

    constructor(
        authApi: IAuthApi,
        googleAuth: IGoogleAuth,
        localStorage: ILocalStorage,
    ) {
        this._authApi = authApi;
        this._googleAuth = googleAuth;
        this._localStorage = localStorage;
    }

    signInWithGoogle(): Promise<User> {
        throw new Error("Method not implemented.");
    }
}

We simply added some private fields, and initialized them inside the constructor.
The fields should be private because it doesn't make sense to be able to access a data source from the repository.

Also, It's important to pass the dependencies in the constructor. First, we don't have to write implementations for the data sources right away as you can see. Also, injecting the dependencies like this enables us to pass-in mock implementations of the data sources, which will make testing a breeze.

Now we can write the actual implementation of signInWithGoogle():

async signInWithGoogle(): Promise<User> {
      const token = await this._googleAuth.signIn();
      const user = await this._authApi.signInWihGoogle(token);
      await this._localStorage.write('accessToken', user.accessToken);
      return user;
}

That's it, our repository is now implemented. We can immediately start testing it, which we'll do in a moment. But before that...

ERROR HANDLING

We haven't done any error handling so far. Our repository looks very unsafe at the moment, anything can go wrong. For instance, the user's network may be unstable, and some request will timeout. Or something can go wrong with google auth, you never know. It's a very messy and unpredictable world out there in the data layer.

Yes you can wrap all calls to the repository in a try catch block but... do you really want to do that? First of all, you won't be obligated to do so, no linter rules will remind you, there won't be any compile time errors, you can easily forget it. You don't want your app to crash because you forgot to catch an error. Second of all, try catch is just ugly.

There is another benefit of using the repository pattern: You can catch all errors inside the repository, and you'll never need to write a try catch again outside of it. First, we need to specify all types of errors that can occur during authentication, to keep it simple, let's say that 2 types of errors can happen:

Network error: If the user is offline or the connection is unstable
General error: Something else happened

We can represent these errors in many ways, I prefer to use an enum:

enum AuthError {
  general,
  network,
}

Then, we need to make our function return an AuthError instead of a User if some exception was raised. At first, I tried to make it return a union AuthError | User, but I didn't find a good way to check exact type of the return value. I could use a type guard, but I think there is a nicer way. The fp-ts library provides us with many functional programming goodies, including the Either type:

type Either<E, A> = Left<E> | Right<A>

As you can see, an instance of Either is either an instance of Left or Right. Convention dictates that Left is used for failure and Right is used for success (see the docs).

Let's change the return type of our signInWithGoogle function, to return Either<AuthError, User>, we should do it in both the interface and the implemented class, here's how it'll look like:

 interface IAuthRepository {
   signInWithGoogle(): Promise<Either<AuthError, User>>;
 }

In the implementation, we return right(user) instead of user if everything went well, if not, we return left(error):

async signInWithGoogle(): Promise<Either<AuthError,User>> {
  try {
    const token = await this._googleAuth.signIn();
    const user = await this._authApi.signInWihGoogle(token);
    await this._localStorage.write('accessToken', user.accessToken);
    return right(user);
  } catch (e) {
    // Check for the type of error here
    // and return the corresponding value
    // if (e is a network error)
    //   return left(AuthError.network);
    return left(AuthError.general);
  }
}

Now, whenever we call signInWithGoogle, we must check if the returned value is of type left or right, and then proceed:

const result = await authRepo.signInWithGoogle();
if (isRight(result)) {
  // The sign in succeeded
  const user = result.right;
  // do something with the user
} else {
  // The sign in failed
  const error = result.left;
  // do something with the error
}

Using this method, all exceptions stop propagating when they arrive to the repository, and they're converted to regular objects that we can deal with later.

Testing

Here comes the fun part, since we implemented our repository the way we did, it's very easy to test it now. Since all of its dependencies are injected in the constructor, we can simply create mock dependencies, and instanciate a repository with them. You can get away with this using jest mocking, but I think there's a better way.

Enter Mockito

There's a very cool library called ts-mockito, it works very well when you use dependency injection in your code (as we're doing now). It allows you to create mocks, stub function calls, and many other cool features, definitely check it out! I'm going to use it to test our AuthRepository.

Take a look at this long test file, I will walk you through it using comments:

import { left, right } from "fp-ts/lib/Either";
import { anything, instance, mock, reset, verify, when } from "ts-mockito";
/// Also import the interfaces and other things...

/// Create mock dependencies
const MockGoogleAuth = mock<IGoogleAuth>();
const MockAuthApi = mock<IAuthApi>();
const MockStorage = mock<ILocalStorage>();

/// Instatiate AuthRepository with the mocks
const authRepo: IAuthRepository = new AuthRepository(
  instance(MockAuthApi),
  instance(MockGoogleAuth),
  instance(MockStorage)
);

// Reset the mocks before each test
// So tests won't be dependent of each other
beforeEach(() => {
  reset(MockAuthApi);
  reset(MockGoogleAuth);
  reset(MockStorage);
});

// Testing `signInWithGoogle`
describe("signInWithGoogle", () => {
  // Test case 1
  test("should persist and return the user if all goes well", async () => {
    // arrange
    const googleToken = "googleToken";
    const user: User = { accessToken: "accessToken" };
    // When signIn is called on MockGoogleAuth, resolve with `googleToken`
    when(MockGoogleAuth.signIn()).thenResolve(googleToken);
    // When signInWithGoogle is called on MockAuthApi, resolve with `user`
    when(MockAuthApi.signInWihGoogle(googleToken)).thenResolve(user);
    // act
    const result = await authRepo.signInWithGoogle();
    // assert
    // the result should be `right(user)`
    expect(result).toStrictEqual(right(user));
    // MockGoogleAuth.signIn should be called once
    verify(MockGoogleAuth.signIn()).once();
    // MockAuthApi.signInWithGoogle should be called once, with `googleToken`
    verify(MockAuthApi.signInWihGoogle(googleToken)).once();
    // The access token should be persisted
    verify(MockStorage.write("accessToken", user.accessToken)).once();
  });

  test("should return an auth error if something wrong happened", async () => {
    // arrange
    // Make it so GoogleAuth throws an exception
    when(MockGoogleAuth.signIn()).thenReject(new Error("some error"));
    // act
    const result = await authRepo.signInWithGoogle();
    // assert
    // the result should be `left(AuthError.general)`
    expect(result).toStrictEqual(left(AuthError.general));
    // MockGoogleAuth.signIn should be called once
    verify(MockGoogleAuth.signIn()).once();
    /// MockAuthApi.signInWithGoogle should never be called
    verify(MockAuthApi.signInWihGoogle(anything())).never();
    // No access token should be persisted
    verify(MockStorage.write("accessToken", anything())).never();
  });
});

Hopefully, this testing strategy was clear, and it gave you an idea of how to test your code in the future. I think it's pretty simple.

Conclusion

Here are the main points we learned throughout this article:

The repository: A component/class that groups multiple data sources, and exposes an API, that hides all its implementation details. It also serves as an "error buster", it catches all those wild exceptions, and returns regular objects in case of a failure.
Abstraction (using interfaces): Using interfaces gives you the ability to have multiple implementations for the same API (mock and real implementations for example). It also makes it easy to change AuthApi for example, from a REST implementation to GraphQL... etc.. It speeds up the development process, especially if you're working as a team. You just setup an interface, and start implementing other things that depend on it. As you saw in this article, we implemented the whole repository without having any implementations of AuthApi, nor any of its other dependencies.
Dependency injection: We didn't get into much details of DI in this article, but we saw how injecting dependencies into a class constructor, makes it very easy to test it. Also, without doing this, we wouldn't have the ability to implement the repository, until we implement all its dependencies. You can say that abstraction and DI complement each other.
Some useful libraries:
1. ts-mockito: A very convenient library that helps you with mocking, and testing in general.
2. fp-ts: A library that brings all of functional programming goodies to typescript. We only used the Either type in this article, but it offers a lot more.

I hope you had a good read, bye bye.

Build a gallery app using Flutter

Abdou Ouahib — Sun, 01 Nov 2020 19:16:45 +0000

At some point, we all needed to access photos in the phone's storage, either to upload it to a backend, or just to display it in a Widget. Either way, the only choice we had was to use the famous image_picker plugin or some other plugin that uses the same approach.

Not too bad

These plugins are awesome and are enough for many use-cases, But sometimes we want more than just selecting a few photos using an external app. What if we wanted to build that external app itself? Or even less enthusiastic, what if we simply wanted to show a ListView with all the images in the phone's storage?

I got you

This would've been quite hard to achieve if not for this awesome photo_manager plugin. All you need to do is call two functions, and you'll get every album and every photo and video on your phone. Let's take a look at some code snippets:

final albums = await PhotoManager.getAssetPathList();

albums will now hold a list of every album in the storage. An album is represented by the AssetPathEntity class, let's take a look at the info it holds:

class AssetPathEntity {
  ...

  // The albums' ID
  String id;
  // The albums name
  String name;
  // How many assets the album holds
  int assetCount;
  // The album's type
  int albumType;

  ...
}

But that's not all, the album class has two very nice methods, that return the photos and videos (assets) it holds.

If you want to get a range of assets use this:

final albumAssets = await album.getAssetListRange(
    start: startIndex,
    end: endIndex,
);

If you wanna use pagination, use this instead:

final albumAssets = await album.getAssetListPaged(
    page,
    assetPerPage,
);

Both these methods return a list of AssetEntity objects, which represents a single photo/video (or other). Again, let's highlight some of the main properties of AssetEntity:

...
// Get the asset's thumbnail bytes
Future<Uint8List> get thumbData;
// Get the asset bytes
Future<Uint8List> get originBytes;
// Get the asset file
Future<File> get file;
// If the asset is a video, get its duration
int duration;
// The width of the asset
int width;
// The height of the asset
int height;
...

In short, we have everything we need to display and pick photos/videos, without quitting our lovely Flutter application.

Let's start building

Okay, now that we finished exploring the main functionality of the plugin, let's put all that knowledge to use. Here's what the final product will look like:

1- Cloning the base project and installing the plugin

First, start by cloning the base project from the link below. Or if you want, you can apply everything directly to one of your own projects.

https://github.com/aouahib/photo_manager_demo_base

Now let's install the photo_manager plugin, go to your pubspec.yaml file and add the dependency:

dependencies:
  photo_manager: ^0.5.8

iOS config

Add these lines to your Info.plist file:

<key>NSPhotoLibraryUsageDescription</key>
<string>The app needs to access your photo library</string>

Android config

You don't need to do any platform-specific configuration.

By now, you should be good to go, make sure the app runs on your device (don't forget to flutter pub get though).

2- Requesting permission

The base project is very simple, the first screen contains a button, clicking on it navigates us to another screen where we are going to display the photos/videos. For simplicity, everything is located in a single file: lib/main.dart

First, we need to ask the user for permission to access the external storage. Let's make sure we have that permission before navigating to the second page. Go to the MyApp class and modify the code as follows:

// import the library
import 'package:photo_manager/photo_manager.dart';

...

return RaisedButton(
  // make the function async
  onPressed: () async {
    // ### Add the next 2 lines ###
    final permitted = await PhotoManager.requestPermission();
    if (!permitted) return;
    // ######
    Navigator.of(context).push(
      MaterialPageRoute(builder: (_) => Gallery()),
    );
  },
  child: Text('Open Gallery'),
);

This simply requests permission, and if it's not granted, we don't navigate to the next screen. Run the app and make sure it works.
NOTE: After installing new plugins, quit the app completely and re-run it from cold, otherwise, you will get errors

3- Fetching photos and videos

Now the fun part begins. Head to the Gallery class. As you see, it's a StatefulWidget with no state so far. Let's start by declaring some state variables:

class _GalleryState extends State<Gallery> {
  // This will hold all the assets we fetched
  List<AssetEntity> assets = [];
  ...
}

Next, let's write a function that fetches the assets, and updates the state. Add the following code somewhere inside the _GalleryState class, I explain everything in the comments:

_fetchAssets() async {
  // Set onlyAll to true, to fetch only the 'Recent' album
  // which contains all the photos/videos in the storage
  final albums = await PhotoManager.getAssetPathList(onlyAll: true);
  final recentAlbum = albums.first;

  // Now that we got the album, fetch all the assets it contains
  final recentAssets = await recentAlbum.getAssetListRange(
    start: 0, // start at index 0
    end: 1000000, // end at a very big index (to get all the assets)
  );

  // Update the state and notify UI
  setState(() => assets = recentAssets);
}

NOTE: If the phone has too many photos/videos, the function above will take too much time to execute. So for better practice, you should implement some kind of pagination using getAssetListPaged()

This function should be called when we first navigate to the Gallery screen, so override initState and call it from there:

@override
void initState() {
  _fetchAssets();
  super.initState();
}

Finally, just to make sure everything works, modify the text widget so it displays the number of assets in the list:

@override
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(
      title: Text('Gallery'),
    ),
    body: Center(
      // Modify this line as follows
      child: Text('There are ${assets.length} assets'),
    )
  );
}

Run the app, open the gallery, and if you didn't make any mistakes, the displayed number should be greater than 0 (Unless you have no photos/videos on your phone :p), something like this:

Good job, you're halfway there, all we need to do now is display the fetched assets.

4- Displaying photos and videos

We're going to display a GridView with the thumbnails of the assets. One way of getting the thumbnail is to use the thumbData getter of the AssetEntity object. It returns a Future<Uint8List> representing the actual bytes of the thumbnail. So we will be using an Image.memory() widget to display it. Let's use all of this to make an AssetThumbnail widget. Copy the code below somewhere in main.dart:

class AssetThumbnail extends StatelessWidget {
  const AssetThumbnail({
    Key key,
    @required this.asset,
  }) : super(key: key);

  final AssetEntity asset;

  @override
  Widget build(BuildContext context) {
    // We're using a FutureBuilder since thumbData is a future
    return FutureBuilder<Uint8List>(
      future: asset.thumbData,
      builder: (_, snapshot) {
        final bytes = snapshot.data;
        // If we have no data, display a spinner
        if (bytes == null) return CircularProgressIndicator();
        // If there's data, display it as an image
        return Image.memory(bytes, fit: BoxFit.cover);
      },
    );
  }
}

Now, instead of showing the number of assets, let's change the code to show a GridView of AssetThumbnail widgets. Go to _GalleryState class, and change the build method:

@override
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(
      title: Text('Gallery'),
    ),
    body: GridView.builder(
      gridDelegate: SliverGridDelegateWithFixedCrossAxisCount(
        // A grid view with 3 items per row
        crossAxisCount: 3,
      ),
      itemCount: assets.length,
      itemBuilder: (_, index) {
        return AssetThumbnail(asset: assets[index]);
      },
    ),
  );
}

That's it, re-run the app and you should see all your photos/videos displayed on the gallery screen

Almost done

You did it! Congrats on reaching this far, we're finally seeing some results. We're almost done, let's make the thumbnails clickable, so we can display the original asset on a new screen. Also while we're on it, let's add a Play icon on top of the thumbnail if it's a video, because right now we can't differentiate between the two types. Go to the AssetThumbnail widget and modify the build method as follows:

@override
Widget build(BuildContext context) {
  // We're using a FutureBuilder since thumbData is a future
  return FutureBuilder<Uint8List>(
    future: asset.thumbData,
    builder: (_, snapshot) {
      final bytes = snapshot.data;
      // If we have no data, display a spinner
      if (bytes == null) return CircularProgressIndicator();
      // If there's data, display it as an image
      return InkWell(
        onTap: () {
          // TODO: navigate to Image/Video screen
        },
        child: Stack(
          children: [
            // Wrap the image in a Positioned.fill to fill the space
            Positioned.fill(
              child: Image.memory(bytes, fit: BoxFit.cover),
            ),
            // Display a Play icon if the asset is a video
            if (asset.type == AssetType.video)
              Center(
                child: Container(
                  color: Colors.blue,
                  child: Icon(
                    Icons.play_arrow,
                    color: Colors.white,
                  ),
                ),
              ),
          ],
        ),
      );
    },
  );
}

Re-run the app, and if you have any videos, you'll see a play icon on top of their thumbnails.

Displaying the original image/video

The asset data can be retrieved as a File using the file getter of the AssetEntity objects.

For images

We can simply display the original image using Image.file(), let's create the ImageScreen widget:
NOTE: make sure to import File from dart:io and not dart:html

class ImageScreen extends StatelessWidget {
  const ImageScreen({
    Key key,
    @required this.imageFile,
  }) : super(key: key);

  final Future<File> imageFile;

  @override
  Widget build(BuildContext context) {
    return Container(
      color: Colors.black,
      alignment: Alignment.center,
      child: FutureBuilder<File>(
        future: imageFile,
        builder: (_, snapshot) {
          final file = snapshot.data;
          if (file == null) return Container();
          return Image.file(file);
        },
      ),
    );
  }
}

Now go to the onTap method of the AssetThumbnail class, and navigate from there to the newly created ImageScreen:

...
return InkWell(
  onTap: () {
    if (asset.type == AssetType.image) {
      Navigator.push(
        context,
        MaterialPageRoute(
          builder: (_) => ImageScreen(imageFile: asset.file),
        ),
      );
    }
    // TODO: navigate to the video screen
  },
...

Re-run the app, click on an image thumbnail, and you should navigate to another screen containing the full image.

For videos

We'll be using the video_player plugin. You can find a better tutorial for this plugin here in case the following code was hard to understand. Anyway, let's create a VideoScreen widget:

Add the dependency

dependencies:
  video_player: ^0.11.1+2

After running flutter pub get, import the library:

import 'package:video_player/video_player.dart';

Add the `VideoScreen` widget

class VideoScreen extends StatefulWidget {
  const VideoScreen({
    Key key,
    @required this.videoFile,
  }) : super(key: key);

  final Future<File> videoFile;

  @override
  _VideoScreenState createState() => _VideoScreenState();
}

class _VideoScreenState extends State<VideoScreen> {
  VideoPlayerController _controller;
  bool initialized = false;

  @override
  void initState() {
    _initVideo();
    super.initState();
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  _initVideo() async {
    final video = await widget.videoFile;
    _controller = VideoPlayerController.file(video)
      // Play the video again when it ends
      ..setLooping(true)
      // initialize the controller and notify UI when done
      ..initialize().then((_) => setState(() => initialized = true));
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: initialized
          // If the video is initialized, display it
          ? Scaffold(
              body: Center(
                child: AspectRatio(
                  aspectRatio: _controller.value.aspectRatio,
                  // Use the VideoPlayer widget to display the video.
                  child: VideoPlayer(_controller),
                ),
              ),
              floatingActionButton: FloatingActionButton(
                onPressed: () {
                  // Wrap the play or pause in a call to `setState`. This ensures the
                  // correct icon is shown.
                  setState(() {
                    // If the video is playing, pause it.
                    if (_controller.value.isPlaying) {
                      _controller.pause();
                    } else {
                      // If the video is paused, play it.
                      _controller.play();
                    }
                  });
                },
                // Display the correct icon depending on the state of the player.
                child: Icon(
                  _controller.value.isPlaying ? Icons.pause : Icons.play_arrow,
                ),
              ),
            )
          // If the video is not yet initialized, display a spinner
          : Center(child: CircularProgressIndicator()),
    );
  }
}

Navigate to it

Go to the onTap method of the AssetThumbnail class, and modify it as follows:

...
return InkWell(
  onTap: () {
    Navigator.push(
      context,
      MaterialPageRoute(
        builder: (_) {
          if (asset.type == AssetType.image) {
            // If this is an image, navigate to ImageScreen
            return ImageScreen(imageFile: asset.file);
          } else {
            // if it's not, navigate to VideoScreen
            return VideoScreen(videoFile: asset.file);
          }
        },
      ),
    );
  },
...

Re-run the app again, now click on a video thumbnail, and you should navigate to a new screen where you can play the video.

NOTE: After installing new plugins, quit the app completely and re-run it from cold, otherwise, you will get errors

That's a wrap

Congrats! We're done with this tutorial. You just built a Gallery app using Flutter. You can apply this knowledge in a lot of use-cases. For example, if you're making a chat app, you can directly display photos and videos on the chat screen, and the user will be able to send them directly without quitting the app (Below are screenshots of Whatsapp and Messenger apps).

You can find the final code in this github repo. If you have any questions, just ask them in the comments and I'll try to help. Bye Bye!

DEV Community: Abdou Ouahib

Fullstack Ethereum Development Course

I built a chat app using React and GraphQL

TLDR

Intro

Disclaimer

The first steps

Building the app

The tech stack

Frontend

Backend

Setup

App features

Authentication

User profiles

Friends

Notifications

Messaging

Realtime

Next.js and Vite.js

Hosting

The hard parts

Configuration

Styling

Virtualization

Keeping everything tested

Things I'm not proud of

Theming

Routing

App size

Final thoughts

Step up your Redux game with Typescript

What we are building

Getting started

The folder structure

The Store

The Slice

Async Thunks

Dependency injection

Reducers

Hooking redux to the components

Custom redux hooks

Auth actions

The store

Providing

Hooking the App component

The Login page

The LoggedIn page

Logging out

Testing

Homework

Conclusion

The Repository pattern with Typescript

The Repository

Abstraction is your friend

Implementations

ERROR HANDLING

Testing

Enter Mockito

Conclusion

Build a gallery app using Flutter

Not too bad

I got you

Let's start building

1- Cloning the base project and installing the plugin

iOS config

Android config

2- Requesting permission

3- Fetching photos and videos

4- Displaying photos and videos

Almost done

Displaying the original image/video

For images

For videos

Add the dependency

Add the VideoScreen widget

Navigate to it

That's a wrap

Add the `VideoScreen` widget