Feat: Proxy Chain Filtering

[rumzledz]

Description

This PR only focuses on enabling Proxy Chain filtering for the Incoming, Balance & Activity pages.

During development, I have identified a couple of filter-related issues which are already present outside my PR. I have no intention of fixing these under this PR but I am more than happy to deal with them separately 😄

👉 CLICK TO SEE ALL ISSUES IDENTIFIED 👈

Issue 1: On mobile view, the Incoming page's search filter popup automatically renders when the filter popup is rendered

Issue 2: When you deploy a Proxy Colony, you will naturally have a scenario where you have the same Token in both Colonies. This results in duplicate Token symbol entries due to how the Token filters components are set up:

Issue 3: Ticking the checkbox for a non-unique Filter entry results in duplicate ticks:

Issue 4: The Incoming page's active filters list gets clipped when the viewport width is narrow:

Issue 5: On the Activity page, filtering by the Split & Staged payment types seemingly does nothing due to how it's implemented 😅

Now that those are out of the way, here's Chain filtering in action:

Incoming page

Balances page

Activity page

Future refactor plans

I had some observations and found some challenges while implementing this which I intend to address in the future.

Note

These are just my thoughts of course.

👉 CLICK IF YOU'RE INTERESTED 👈

Filter Construct

Our filters are quite straightforward. They are mostly maps of string => boolean. Now while this is efficient, it doesn't allow for more flexibility when it comes to attaching metadata for a filter. For example, I wanted a Chain filter to carry both the label and the chain ID and I couldn't. As a result, I have to make a separate lookup to identify a Chain filter's corresponding Chain ID. I made some filter construct adjustments for the Balances page to make this more convenient for me:

filters = {
  chain: {
    [name of the filter]: {
      isChecked: boolean;
      id?: string; // Intended to be the Chain ID in this scenario but it could be any other thing tbh
    }
  },
  someOtherFilter: {
    [name of the filter]: {
      isChecked: boolean;
      id?: string;
    }
  }
}

This approach isn't perfect but it was the path of least resistance. I found that it required the most minimal adjustments to keep it compatible with our overall filter set up and at the same time, allow me the flexibility I needed. I want to come up with a better solution in the future but I'll be basing my future work on this concept.

Filter fragmentation

I found that we have multiple filter approach across our pages but most of them follow the same sort of structure. We tend to have multiple states to store filter chunks i.e.

const [tokenFilters, setTokenFilters] = useState();
const [otherFilter, setOtherFilter] = useState();

// dupe
const handleTokenFilterChange = (event) => {
  const isChecked = event.target.checked;
  const { name } = event.target;
  
  setTokenFilters(state => ({ ...state, [name]: isChecked }));
}

// dupe
const handleOtherFilterChange = (event) => {
  const isChecked = event.target.checked;
  const { name } = event.target;
  
  setOtherFilter(state => ({ ...state, [name]: isChecked }));
}

I came up with a unified approach for the Balance page filters as a POC but I made sure it didn't require me to make some major code-breaking changes across the board. I want to explore this concept further in the future.

const handleFiltersChange = (event, type) => {
  const { checked, name, id } = event.target;
  
  setFilters(state => ({
    ...state,
    [type]: {
      ...state[type],
      [name]: {
        isChecked: checked,
        id // I assigned the Chain ID to the id prop of the checkbox input
      }
    }
  });
}

// Usage
<input
  id={chainId}
  name={chainLabel}
  onChange={event => handleFiltersChange(event, 'chain')}
/>

We also have Filter components that can be unified and re-used across different pages but I understand why we have to duplicate them in our current setup.

Testing

Important

1. Bring up the Manage supported chains form
2. Add support for Local Proxy Chain 1 and submit the form

1. Visit the Incoming page
2. Filter the table by Chain -> Local Proxy Chain 1
3. Verify that you can only see the ETH entry for Chain 265669101
4. Visit the Balances page
5. Filter the table by Chain -> Local Proxy Chain 1
6. Well, this one is a bit awkward because there's not much to go by.. BUT, you should only see 1 ETH entry because the other hidden one is not from Chain 265669101
7. Visit the Activity page

Warning

At the moment, if you filter by the main chain (Ganache in this instance), it won't work because actions have their targetChainId set to null by default. Our GraphQL is not set up to filter by null.

In fact, if you tried to filter by the Main Chain, you will get no results because the API itself returns an empty array.

The best recommendation was to perform a migration which pretty much checks if an action was made on the main chain, indicated by a null value for targetChainId and replaces it with the Main Chain ID.

This will be dealt with separately. So for now, please just try out Proxy chain filtering for the Activity page.

9. Filter the table by Chain -> Local Proxy Chain 1
10. Verify that you can see the Manage supported chains action you did earlier

Resolves #3461

[mmioana]

Hey @rumzledz really nice start on this issue! 💯

I haven't given it a proper review yet, but I noticed we display all proxy chain options even before the colony has deployed one, which should not be the case.
We'll need to make use however of the active proxy chains when filtering the chain options. So, we'll need something among these lines

  const activeProxyColoniesChainIds = useDeployedChainIds({
    filterFn: (deployedProxyColony) => deployedProxyColony?.isActive,
  });

  const chainOptions = useChainOptions({
    filterOptionsFn: (option) =>
      activeProxyColoniesChainIds?.includes(option.value.toString()) ||
      option.value === DEFAULT_NETWORK_INFO.chainId,
  });

Also, we'll need to add the default chain as an option to filter. You can have a look over @bassgeta's work here

[mmioana]

Really fine work once again @rumzledz 🎉

Before deploying a proxy colony the chain options show properly for the Manage supported chains action. Tested also after deploying if the options update properly

And all the filters show up very nicely 🥇

Disabled a proxy colony and the proxy chain is no longer among the filtering options

✨