Forem: ghack.dev

Clean Code for "Adult"

ghack.dev — Mon, 27 Apr 2020 18:59:10 +0000

🌙 Tonight, I decided to do nothing but reading. I just randomly went to some blogs and articles until I found one article written by Dan Abramov.

That article had spoken an immense wisdom to me. It was talking about Clean Code that maybe we can found it everywhere because everyone has been talking about Clean Code for a long time ago.

But I found it's different. In that article, Dan Abramov was looking at Clean Code from the "Adult" perspective. Based on one of his true experiences, he said that it took years to realize that he was looking at Clean Code from the "Child" perspective.

The Story Began...

Once upon a time, Dan and his colleague are working on the same project. For more detail you can read the full article here because I just want to summarize the whole story.

Dan's colleague and the team had finished coding on some functionalities. And their code worked and everything was fine. But when Dan saw the code, he found that the code was repetitive or maybe he can just say that the code isn't clean.

Apparently, Dan has an Idea to make the code "Cleaner" from Dan's perspective at that time. Eventually, he did it. The code is half the total size and the duplication is gone completely. Which is good. It was more than enough to carry Dan to the very tight sleep because it was already late at night at that time. 😴

The Next Morning...

The plot twisted. Dan's boss and the team politely asked Dan to revert the changes. Dan was aghast. Yeah, the code was a mess and Dan's code was clean! 😲

It took years for Dan to see they were right.

👶 Childish Mindset

Do you remember your reaction when you hear about Clean Code for the first time? Obsessed. Yeah, maybe that's a phase that many of us go through.

Yeah, just like a kid when Dad comes home and brings the coolest toy among his friends. The kid will always try to proudly show off his new to cool toy to his friends.

In the time that we acquired the Clean Code as our new superpower, we'll always try to implement it everywhere whenever we feel unconfident with our code. Just like a superhero that always wants to bring justice whenever he encounters bad things.

“I’m the kind of person who writes clean code” 🦸‍♂️

The Turning Point

Eventually, Dan realized that "refactoring" the code at that time was a disaster. There are two points :

First, Dan didn't talk with the people who wrote the code he refactored. It destroys the trust between each other in the engineering team.
Second, Dan's code traded the ability to change requirements for reduced duplication, and it was not a good trade.

So, should we write dirty code instead?

No. From this story, we could learn that we should think deeply before we could decide to do something. It's not only about "clean" or "dirty" code. Because clean code is not the goal.

In the real world, sometimes we need to shrink our ego, pride, or idealism down. Because we should consider seeing the problems from different perspectives.

🌱 Coding is a Long Journey

I believe that coding is a long long journey, when I saw my first line of code in my repository I posted about 3 years ago, I saw a lot of transformations in a lot of aspects in the term of coding.

The more I learned about concepts, paradigms, architecture, and also looking at problems from different perspectives, the more I realize that we should think more deeply before we could decide or use something.

Conclusions

Remember the story about the kid I told you earlier in this article? Imagine that you are the kid in that story. And right now, you are not a kid anymore, you are an adult now, and you just realized that the toy given by your Dad is not just a toy.

Because you're looking at the gift from your Dad from a child's perspective you saw it like it's a toy. But when you see it from an adult's perspective finally you understand that it's a computer and you realize that you could build something amazing with it!. 👨‍💻

But, besides that, you should also realize that from another perspective, you could also do bad things that could harm the others with that computer.

So, in my opinion, it's about perspective. Don't let your understanding about Clean Code or other fancy things shackle you to see problems or solutions from different perspectives.

Let clean code guide you. Then let it go. -- Dan Abramov

Optimistic UI Trick Revealed!

ghack.dev — Sun, 26 Apr 2020 05:12:41 +0000

Fake it, 'til you make it.

Suddenly I remember that quote when I'm talking about Optimistic UI. Before I understand what Optimistic UI is, I just wondering that how a response could be that fast. 😳 For example, look at Instagram like UI.

There is no boring loading icon. When we press the like button, it will immediately liked the post. That's awesome right? 😲

When a Magician 🎩 performs a trick, we could be easily amazed until someone revealed the trick.

So, How Optimistic UI works?

Let's reveal the secret behind the Optimistic UI trick.

Optimistic UI is a pattern that you can use to simulate the results of a mutation and update the UI even before receiving a response from the server. Once the response is received from the server, the optimistic result is thrown away and replaced with the actual result. -- Apollo GraphQL

"Simulate the results" means that we need to fake the response first, before we receive the real one. That's it. 💁‍♂️

Example

We could implement this pattern easily using Apollo Client. This is one of the benefits of using GraphQL because the request and response are defined earlier in the Query and Mutation schema, we could easily fake the response while ensuring that the data becomes consistent with the actual response when it arrives.

const LIKE_POST = gql`
  mutation LikePost($postID: ID!) {
    likePost(postID: $postID) {
      id
      __typename
      likers
    }
  }
`

const Posts = () => {
  const username = useSelector(state => state.auth.username)
  const [mutate] = useMutation(LIKE_POST)
  return (
    <Comment
      updateComment={({ id, likers }) =>
        mutate({
          variables: { postID: id },
          optimisticResponse: {
            __typename: "Mutation",
            likePost: {
              id,
              __typename: "Post",
              likers: [...likers, username]
            }
          }
        })
      }
    />
  )
}

Now, this trick couldn't amazed us anymore. 😅

React Instant Theme Toggler using pure CSS

ghack.dev — Thu, 23 Apr 2020 02:44:11 +0000

Dark Mode is everywhere right now. To boost the user's experience, the App needs to be customizable to satisfy the user's personal taste. Some people are love to see a light clean view and some other people are love to see a dark and elegant view.

CSS Variable

CSS variable or CSS custom properties are just like a variable in a programming language. This feature of CSS enables us to create a variable that can be changed on the fly via DOM.

This feature is available on pure CSS. We don't need any other library or CSS preprocessor to be able to use it. With this feature we can do theming on our web app easily. So the users can change the theme on the fly seamlessly.

How to do Theming with pure CSS in React?

First, all we need to do is declaring some default variables first. In our CSS file.

:root {
  --color-primary: #282c34;
  --color-background: white;
}

And then, we can put the logic to change the theme inside a hook named useTheme.

import { useEffect } from 'react';

const themes = {
  light: {
    "--color-primary": "#282c34",
    "--color-background": "white"
  },
  dark: {
    "--color-primary": "white",
    "--color-background": "#282c34"
  },
}

const useTheme = (selectedTheme) => {
  useEffect(() => {
    const theme = themes[selectedTheme] || themes.light;
    Object.keys(theme).forEach(key => {
      const value = theme[key];
      document.documentElement.style.setProperty(key, value);
    });
  }, [selectedTheme]);
};

export default useTheme;

As you saw that we have a variable called themes, inside that variable object, we can put as many themes as we want, in this case, I only put two kinds of themes, dark and light.

We can use useEffect hook to listen to whether the selectedTheme variable changed. And then, if the selectedTheme changed, we iterate the theme object's keys, and change our CSS Variable on the fly by accessing document object and set document's style property with key and value from our theme object.

After that, we can use useTheme hook in our component.

const [darkModeEnabled, setDarkModeEnabled] = useState(false);
useTheme(darkModeEnabled ? 'dark' : 'light');

And maybe we can use the HTML checkbox to toggle the theme.

 <label for="theme-toggler"> 
  <input
    id="theme-toggler"
    type="checkbox"
    checked={darkModeEnabled}
    onChange={e => setDarkModeEnabled(e.target.checked)}
  /> 
  DarkMode Enabled
</label><br />

Pretty easy right?

Yeah, the app's theme will change instantly as we click the theme toggle. With this very simple approach, we can give the user a seamless experience to give the user the capability to personalize the app based on their own taste.

Find it useful?

Follow @ghack.dev on Instagram and watch a lot of useful tutorials in Ghack Dev's Youtube channel. See you!

A Journey From Monolith to Micro Everything

ghack.dev — Sat, 18 Apr 2020 06:23:30 +0000

Chapter I - The Monolith

Let's imagine we're a developer that working in a small startup company that needs an e-commerce like web app to serve the customers. In the early start of our startup, we need to deliver our app as soon as possible to validate the business model and to retrieve quick feedback from our potential customers. So, we decided to start to build the app with this architecture :

This is a very simple architecture and there are only a few members in the teams that working on this app. The front-end and back-end app codebases are managed by a single team for each codebase.

The database shared across multiple APIs managed by our monolith backend that also includes some APIs to integrate with some APIs from third-party companies.

Chapter II - The Microservice

The number of our customers are growing. The business requirements are also increasing. More and more features need to be added to fulfill the customer's needs.

Because the codebase is getting more difficult to maintain and deploy because a lot of new features and functionalities need to added and also a lot of people working on it, we decided to split the monolithic backend to microservices. So this is our current system architecture :

Now, our backend transformed from a single monolith instance become multiple instances of microservice. Each microservice is managed by a single team. They're independent and loosely coupled. Even we can use different frameworks or different programming languages for every instance of our microservices.

And also, rather than using a shared database we decided to use multiple database instances for each microservice. We split the backend into microservices based on the business domain, for example product catalog, transaction, authentication, etc.

If you see the diagram of our new architecture, there is one more node called The Orchestrator that did the orchestration before the front-end can consume it as APIs. For example maybe we can put GraphQL as an orchestrator of our microservices.

Chapter III - The Micro Frontend

We now realize that we have a lot of screens to manage on the front-end side. The number of members in the team that works on the front-end side modifying a single codebase is growing, because the business needs more and more functionalities to satisfy the customers.

After did a lot of discussions there is an idea popped up from one of our front-end team.

How about implementing the same thing as the backend team did on the backend-side to the front-end side?

Is it possible to split the codebase of our monolith client-side app into multiple instances? Just call it micro frontend. Isn't that cool? Because the DDD (Domain Driven Design) a.k.a the microservice is not only for the backend but it could be applied on the front-end.

So we decided to split our monolith front-end codebase, into multiple instances, we called it micro frontend. Right now, our system architecture will be like this :

As you see that now we have multiple instances of micro frontend. Every single micro frontend represents a business domain, just like what we did on the backend side. Every instance of micro frontend is developed by a single team, every instance is independent and loosely coupled.

Even we can use a framework-agnostic approach, it means that we can use different frameworks for each micro frontend instance. Maybe one micro frontend is using React.js and one another is using Vue.js.

Our new system architecture becoming more complex. As you can see that right now we have more than one orchestrator for our microservices, and also we have one more node called Routing to orchestrate and decide which micro frontend that should be loaded.

To be continued ...

NextJS x GraphQL x Apollo Client SSR

ghack.dev — Fri, 17 Apr 2020 07:47:58 +0000

I've built my personal blog (https://www.ghack.dev/) using NextJS, GraphQL with Apollo Server and Apollo Client. My blog is a Progressive and Isomorphic Web App. I experienced a tricky challenge when I want to do Server-side rendering using Apollo Client.

Why i need to do SSR?

I need to do SSR because I want to do SEO and I also need the data from the GraphQL query to fill page title and some meta tags in some pages in my personal blog.

I have read the documentation about Server-side rendering using Apollo Client here :
https://www.apollographql.com/docs/react/performance/server-side-rendering/

But I still confuse about how to implement it on my NextJS project. And then I got inspired by this library :
https://github.com/lfades/next-with-apollo

That is a very simple library that we can use to enable SSR to our NextJS x Apollo Client project. We only need to wrap our Page Component with withApollo HOC from the library.

The idea is to execute getDataFromTree method from the @apollo/react-ssr library and put an extracted AppTree component from the context as a parameter. Just like what's explained in the documentation.

Because I want a very simple implementation and I won't use HOC to execute the getDataFromTree method. I want to execute getDataFromTree inside the getInitialProps in my _app Component.

Maybe you won't include Apollo in all of your pages, in some cases, using HOC is a better approach.

Finally, I've succeed to do that and this is my code :

import React, { useReducer, useEffect, Reducer } from 'react';
import Head from 'next/head';
import ApolloClient from 'apollo-client';
import { ApolloProvider } from '@apollo/react-hooks';
import { InMemoryCache } from 'apollo-cache-inmemory';
import { createHttpLink } from 'apollo-link-http';
import { getDataFromTree } from '@apollo/react-ssr';
import fetch from 'isomorphic-fetch';
import AppContext, { Action, State, reducer, initialValues, appActions } from '@contexts/AppContext';
import useScroll from '@hooks/useScroll';

const link = createHttpLink({
  uri: 'https://my-graphql-server.com/graphql',
  fetch: fetch,
})

const apollo = new ApolloClient({  
  link,
  cache: new InMemoryCache()
});


const App = ({ Component, pageProps }) => {
  const [state, dispatch] = useReducer<Reducer<State, Action>>(reducer, initialValues);
  const [scroll] = useScroll();

  useEffect(() => {
    dispatch(appActions.setScrollPosition(scroll));
  }, [scroll]);

  return (
    <AppContext.Provider
      value={{
        state,
        dispatch,
      }}
    >
      <ApolloProvider
        client={apollo}
      >
        <Component {...pageProps} />
      </ApolloProvider>
    </AppContext.Provider>
  )
};

App.getInitialProps = async ({ Component, ctx }: any) => {  
  let pageProps = {} as any;
  const apolloState = {data: {}};
  const { AppTree } = ctx;

  if (Component.getInitialProps) {
    pageProps = await Component.getInitialProps(ctx);
  }

  if(typeof window === 'undefined') {
    if (ctx.res && (ctx.res.headersSent || ctx.res.finished)) {
      return pageProps;
    }

    try {
      const props = { ...pageProps, apolloState, apollo };
      const appTreeProps =
        'Component' in ctx ? props : { pageProps: props };
      await getDataFromTree(<AppTree {...appTreeProps} />);
    }catch(error) {
      console.error(
        'GraphQL error occurred [getDataFromTree]',
        error
      );
    }

    Head.rewind();

    apolloState.data = apollo.cache.extract();
  }

  return { pageProps };
}  

export default App;

I hope this information can be useful for you. And please, if you have a better idea to improve my code. Please leave a comment below!

The Secret of Producing Less Bug🐞 In Your ReactJS Projects!

ghack.dev — Wed, 15 Apr 2020 15:51:48 +0000

I will start with a very simple question.

Why are we producing a bugs?

🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞🐞
Because we are human, we're making a lot of mistakes while living on this earth. So, what can we do with it? 🤔

Anyone who has never made a mistake has never tried anything new. - Albert Einstein

It's okay to make mistakes. But what i mean by making a mistake here is when you are on a Sunday vacation with your family or a date with your beloved girlfriend or boyfriend until your boss calling you and say that some functionalities in the app that you've built doesn't work or some clients are complaining because there are bugs in the app. 😩

Those kind of conditions will definitely throw away our joyful weekend to the garbage. So, how can we avoid those kind of conditions? One of the best answer of this question is Unit Test.

No time for it! ⏱

Yeah, if we're working on a startup that everything should be delivered ASAP, maybe we can easily say that we don't have time to write unit tests. Especially if we're working as a front-end to build an UI, we'll just let the QA to test it manually.

STOP! ⛔️

Believe me, if you are a React developers and you decide to start to write a tests today. Your life we'll be much easier and happier than before.

It's easy and fast... 🚀

In this article i'll show you that writing tests in React project is a very easy and fast job. Just do some practice, let your muscle memory get used to it, and you'll find it easier to do this job.

I'm not going to show you about how to write tests in React only, but I will also show you how to do TDD in React correctly and how to write a good tests in your React project. So you can enjoy the process of writing the tests, and have a peaceful weekend. 🙆🏻‍♂️

TDD (Test Driven Development)

TDD is about creating a code that we trust and the code that we can proud of. It's very simple, just remember these three steps :

RED. Make it fail.
GREEN. Make it pass.
YELLOW. Refractor.

No cheap talks, let's code! 👨‍💻

Preparation

We'll create a fresh react project and then we'll start using TDD to build a very simple Counter App.

Just install React by using this command :

npx create-react-app react-tdd-sample

Install Enzyme library :

npm i -D enzyme

And also these libraries :

npm i -D react-test-renderer enzyme-adapter-react-16

Create new file named setupTests.js inside src folder or if it exists, just modify the code to be like this :

import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

configure({ adapter: new Adapter() });

Okay I think that we are ready. Let's start writing our component.

1. Write a failing test.

Write a test to prove that the next small piece of functionality is missing or wrong.

Okay first, we'll write a simple failing test. Just create new file called Counter.spec.js inside src/components folder.

import React from 'react';
import { shallow } from 'enzyme';
import Counter from './Counter';

describe('Counter', () => {
  let wrapper;

  it('should render a number', () => {
    wrapper = shallow(
      <Counter />
    );
    expect(wrapper.find('.Counter__container__number').length).toEqual(1);
  });
});

And then, just create a very basic React Component. Create new file named Counter.js in the same folder and write down this code.

import React from 'react';

const Counter = () => {
  return (
    <div className="Counter__container">
      This is Counter component.
    </div>
  );
};

export default Counter;

2. Run the test.

Just run a test by using this command :

npm test

The test should be fail this time. Just make it feel like it's a bug. The reason behind this step is that we need to prove that the test is good. We test the test, it will brings us trust.

3. Refractor the component, as simple as possible to pass the test

To past our first test, we just need to refractor our component to be like this.

import React from 'react';

const Counter = () => {
  return (
    <div className="Counter__container">
      <p
        className="Counter__container__number"
      >
      </p>
    </div>
  );
};

export default Counter;

4. Run the test.

This time, the first test should be passed.

5. Incrementally refractor the test or the Component code.

We know that we only create a <p> tag and there is nothing inside, it's not actually render a number. Let's refractor the codes.

Refractor our test to be like this.

import React from 'react';
import { shallow } from 'enzyme';
import Counter from './Counter';

describe('Counter', () => {
  let wrapper;

  it('should render a number', () => {
    wrapper = shallow(
      <Counter />
    );
    expect(wrapper.find('.Counter__container__number').length).toEqual(1);
    expect(wrapper.find('.Counter__container__number').text()).toEqual('0');
  });
});

And refractor our Counter Component to be like this.

import React from 'react';

const Counter = () => {
  return (
    <div className="Counter__container">
      <p
        className="Counter__container__number"
      >
        0
      </p>
    </div>
  );
};

export default Counter;

6. Run the code.

After do a small refractor to your test code and Component code. Run the code and it should passed.

That's it!

Those steps, from first step to the sixth step. In those steps, we've seen that we have two loops. The inner loop is start from step five to six. We can repeat step five to six until we like the code.

Okay, just look at this picture :

In the picture above, the design happens two times. On the first step of the outer loop and on the first step of the inner loop.

In the outer loop, we're creating a code that we trust. In the inner loop, we're creating a code that we like, the code that we can proud of. You know, sometimes we just write an ugly code that works but we hate it.

Conclusions...

TDD is about creating a code that we trust and the code that we like.

Some questions...

Why do we write test before we write the code?
Otherwise you’ll have no time to write them.

Why do we make the test fail first?

To test the test.

Why do we solve it as simply as possible?

Simpler solutions are easier to maintain.

Why refractor?

To constantly improve the design of the code. Remove duplication and maintainability.

Why work incrementally?

Something working is better than nothing. Small units of work are easier for people better life!

The benefits?

Less bugs!
Better designed interfaces!
Happier life! For customers and coders!

Finish the project!

Okay right now you can practice it yourself. Continue the Counter App project by following the steps. You can add more functionalities like passing an initial value to the counter and create two buttons to increase and decrease the number.

This article is based on this video :
https://www.youtube.com/watch?v=oneGCBiPK_Q

How I use Google Map Javascript API without using any other lib in my NextJS project

ghack.dev — Sat, 28 Mar 2020 05:30:49 +0000

Hello guys, this is my first post on dev.to. In this very first post, I want to share one of my experiences as a front-end engineer at Sayurbox (One of Indonesian Startup).

As I said in the title of this post, it's a Google Map thing. When we are building our mobile web using NextJS, we want to create the features of this mobile web to be similar as our mobile app. One of those features is a Google Map place picker.

There is a famous lib that which allow us to use Google Map in our NextJS project called google-map-react, it's also fully isomorphic and can render on server, but my Senior said "why don't we just use the Google Map Javascript SDK", we only need to show a Google Map and a simple marker at the center of it. And I said, yes that's make sense and it's more challenging for me and I liked it.

Maybe I did a lot of wrong implementations but I just decided to not being shy or afraid that I will getting bullied, the reason why I share something is when I did something wrong, other people can show me the right way. So, please, if you guys have any feedback to improve my code, just leave it in the comment section below :).

And then, some code...

After fiddling around, I finally found the simplest way to do it. I'm still figuring out to improve it's performance. The first thing I did is to load the Google Map Javascript SDK. There is a way to load it on client side using scriptjs lib as the google-map-react lib did, but I have tried it and it produces some bugs and i have no time to fix it, that's why I decided to just put a script loader tag on the head tag because the feature needs to be launched ASAP. But I will fix it later. This the code :

...
import Head from 'next/head';
...

const AddressPage = () => {
  return (
    <App>
      <Head>
         <script async defer src={constants.GOOGLE_MAP_API_URL} />
      </Head>
      ...
    </App>
  )
};

...

After I loaded the Google Map Javascript API, I can use it in my React Google Map View Component. This is the code :

/* eslint-disable no-undef */
import React, { useEffect, useState } from 'react';
import PropTypes from 'prop-types';
import { useSelector } from 'react-redux';
import icLocation from '~/public/assets/icons/ic_location.png';
import icMyLocation from '~/public/assets/icons/ic_my_location.png';
import { getCurrentLocation } from '~/lib/domUtil';
import styles from './styles.json';

const GoogleMapView = ({ width, height, lat, lng, zoom,
  zoomControl, scaleControl, fullscreenControl, disableDefaultUI, gestureHandling,
  mapRef, onDragStart, onDragEnd, showMyLocationButton }) => {    
    const mapDivRef = React.createRef();
    const isTest = useSelector(state => state.view.isTest);
    const [isDragging, setIsDragging] = useState(false);
    const [localMapRef, setlocalMapRef] = useState(null);
    const [latestLocation, setLatestLocation] = useState(null);

    const options = {
      center: {lat, lng},
      zoom,
      disableDefaultUI,
      zoomControl,
      scaleControl,
      fullscreenControl,
      clickableIcons: false,
      clickableLabels: false,
      styles,
    }

    /** 
     * This is hacky becase this google map using external script
     * so when we detect this is a test, the google map will not be rendered.
    */
    if(isTest) {
      return null;
    }

    useEffect(() => {
      if(localMapRef) {
        const newOptions = Object.assign({}, options);
        newOptions.gestureHandling = gestureHandling ? 'greedy' : 'none';
        localMapRef.setOptions(newOptions);
      }
    }, [localMapRef, gestureHandling]);

    useEffect(() => {
      if(localMapRef && lat && lng) {
        localMapRef.setCenter({lat, lng});
      }
    }, [localMapRef, lat, lng])

    useEffect(() => {
      let dragStartListener;
      let dragEndListener;  
      let map = null;    
      if(map === null && mapDivRef.current !== null) {
        onDragEnd(lat, lng);

        map = new google.maps.Map(mapDivRef.current, options);

        getCurrentLocation().then((position) => {
          const { latitude, longitude } = position.coords;          
          const location = {lat: latitude, lng: longitude};
          setLatestLocation(location);

          if(!lat || !lng) {
            onDragEnd(latitude, longitude);
            map.setCenter(location);
          }
        }).catch(() => {})

        dragStartListener = google.maps.event.addListener(map, 'dragstart', () => {
          setIsDragging(true);
          onDragStart();
        });

        dragEndListener = google.maps.event.addListener(map, 'dragend', () => {
          setIsDragging(false);
          const center = map.getCenter();
          onDragEnd(center.lat(), center.lng());
        });

        mapRef(map);
        setlocalMapRef(map);
      }

      return () => {        
        google.maps.event.removeListener(dragStartListener);
        google.maps.event.removeListener(dragEndListener);
      }
    }, []);

    return (
      <div
        style={{ width, height }}
        className="GoogleMapView__container"
      >
        <div
          style={{ width, height }}
          ref={mapDivRef} id="map"></div>
        <img
          id="ic-location"
          className={isDragging ? 'ic-location-up' : 'ic-location-down'}
          src={icLocation}
          alt="sayurbox-ic-location"
        />
        <i
          className={`ic-circle ${isDragging ? 'ic-circle-up' : 'ic-circle-down'}`}
        ></i>
        {(showMyLocationButton && latestLocation) &&
          <div
            className="GoogleMapView__container__icMyLocation"
            role="button"
            onClick={() => {
              if(latestLocation && localMapRef) {
                localMapRef.setCenter(latestLocation);
                onDragEnd(latestLocation.lat, latestLocation.lng)
              }
            }}
          >
            <img
              src={icMyLocation}
              alt="sayurbox-ic-my-location"            
            />
          </div>
        }        
      </div>
    )    
};

GoogleMapView.propTypes = {
  width: PropTypes.string,
  height: PropTypes.string,
  lat: PropTypes.number,
  lng: PropTypes.number,
  zoom: PropTypes.number,
  mapRef: PropTypes.func,
  disableDefaultUI: PropTypes.bool,
  zoomControl: PropTypes.bool,
  scaleControl: PropTypes.bool,
  fullscreenControl: PropTypes.bool,
  gestureHandling: PropTypes.bool,
  onDragStart: PropTypes.func,
  onDragEnd: PropTypes.func,
  showMyLocationButton: PropTypes.bool,
}

GoogleMapView.defaultProps = {
  width: '100%',
  height: '8em',
  lat: -6.291272,
  lng: 106.800752,
  zoom: 16,
  mapRef: () => {},
  disableDefaultUI: false,
  zoomControl: false,
  scaleControl: false,
  fullscreenControl: false,
  gestureHandling: false,
  onDragStart: () => {},
  onDragEnd: () => {},
  showMyLocationButton: false,
}

export default GoogleMapView;

Finally...

Maybe it isn't perfect but it works! :D. We have released it on production right now! This is the demo :

Closing...

Mmm, with this way I learned something that maybe I'm stuck in the mindset to use existing library to do everything without knowing how it works under the hood, when I tried to build something by myself, it gives me more value and useful experience.

I'm not trying to tell you that we don't have to use any existing library because it's not good too to "re-invent the wheels". But, sometimes, building something from scratch can give us precious experience we haven't meet before. Thanks for reading!