feat(counter): Add builders check-in count implementation

[All-Khwarizmi]

Description

Implemented builders check-in counter with two possible ABI handling approaches:

Current Implementation:

// Direct ABI definition approach
const BatchRegistryABI = {
  checkedInCounter: {
    name: "checkedInCounter",
    type: "function",
    stateMutability: "view",
    inputs: [],
    outputs: [{ type: "uint256" }],
  },
} as const;

Alternative Approach (from ContractVariables.tsx):

// Dynamic ABI filtering approach
const abiFunction = (deployedContractData?.abi as Abi)?.filter(
  part => part.type === "function" && part.name === TARGET_FUNCTION_NAME,
)[0] as AbiFunction;

Implementation Considerations:

• Direct ABI is more performant (no runtime filtering for only one function) and more readable
• Dynamic approach is more flexible for contract updates
• Both maintain type safety

Which approach would be preferred in this context?

Additional Information

• Following issue requirements
• Added inline documentation explaining both approaches
• Added comparative analysis in comments

Related Issues

Closes #8

Your ENS/address: 0x7d971C39bb700AcEc20879D46f092dC0DB1dbF9E

[vercel]

@All-Khwarizmi is attempting to deploy a commit to the BuidlGuidl Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
batch12.buidlguidl.com	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 8, 2025 6:43pm

[derrekcoleman]

Thanks for the PR, All-Khwaizmi! Please take a look at my comments for some specific feedback. As to your question,

Implementation Considerations:

• Direct ABI is more performant (no runtime filtering for only one function) and more readable
• Dynamic approach is more flexible for contract updates
• Both maintain type safety
  Which approach would be preferred in this context?

I personally think readability (specifically, maintainability) is quite important for helping us reason through what our code does, something mostly lost in the second option you offer. The fact that the first is more performant is icing on the cake (and potentially irrelevant if you're able to do SSR, as I suggest).

Lastly, I think it's a great habit to include a screenshot of your changes in the PR's description. Please update your original message with a preview of the page with the counter component.

Let us know if you have any questions!

[derrekcoleman]

Is it possible to render this server-side? It's a query for an integer that we render in a component that has no interactivity, so I would think it's a good candidate for SSR.

[All-Khwarizmi]

Went down the rabbit hole of SSR wrt to our case and smart contracts in general and here are my findings:

We have different options in hand to SSR this section:

• For starters we can remove the use client directive from the home page following the same reasoning.
• For the BuildersCheckInCount since we're using hooks we can't as is.
• We could try the pattern composition and have a CounterDisplay (child) server component to render the counter but it might be an overkill for not much since the parent remains client side anyway.
• So why not try to query the counter from the server already using viem's create public client. To do so we would need to remove the hooks, keep the ABI definition and have access to the contract address either programmatically (how?) or hardcoded on last resort.

// BuildersCheckInCount.tsx (Server Component)
import { createPublicClient, http } from 'viem'
import { optimism } from 'viem/chains'

const CONTRACT_ADDRESS = '0x...'

async function BuildersCheckInCount() {
  // Create public client
  const client = createPublicClient({
    chain: optimism,
    transport: http()
  })

  try {
    // Read from contract
    const counter = await client.readContract({
      address: CONTRACT_ADDRESS,
      abi: ABI,
      functionName: FUNCTION_NAME,
    })
...

• Second best approach in my opinion is the suspense one, where we SSR the home page and stream the child client component using the suggested useScaffoldReadContract hook.

// In home page
  <Suspense fallback={<LoadingCounter />}>
            <BuildersCheckInCount />
 </Suspense>

// BuildersCheckInCount
import { useScaffoldReadContract } from "~~/hooks/scaffold-eth";

function BuildersCheckInCount() {
  // Get the result of the target function call from the deployed contract
  const {
    data: counter,
    isLoading,
    error,
  } = useScaffoldReadContract({
    contractName: CONTRACT_NAME,
    functionName: FUNCTION_NAME,
  });

  return (
    <div className="text-lg flex gap-2 justify-center items-center">
      <span className="font-bold">Checked in builders count:</span>
      {isLoading || (!error && !counter) ? (
        <ArrowPathIcon className="size-5 animate-spin" />
      ) : error ? (
        <span className="text-error">Error!</span>
      ) : (
        <span>{displayTxResult(counter)}</span>
      )}
    </div>
  );
}

Notice the isLoading || (!error && !counter) trick to avoid a clunky initial state without any data nor loading state

Without the trick

Enregistrement.de.l.ecran.2025-01-10.a.07.58.50.mov

With it

Enregistrement.de.l.ecran.2025-01-10.a.07.57.29.mov

What do you think is the best approach?
Is there other options that I did not consider?

[derrekcoleman]

For starters we can remove the use client directive from the home page following the same reasoning.

Yup, love it!

We could try the pattern composition and have a CounterDisplay (child) server component to render the counter but it might be an overkill for not much since the parent remains client side anyway.

Even though the parent is client side, it renders quite quickly because it has no fetching to do. In other words, only making the CounterDisplay server-side (to save on its loading time) would still accomplish the goal pretty well without much scope creep.

So why not try to query the counter from the server already using viem's create public client. To do so we would need to remove the hooks, keep the ABI definition and have access to the contract address either programmatically (how?) or hardcoded on last resort.

If you're interested in practicing this implementation, this would be a great exercise. In my opinion hardcoding the contract address is fine, since our context is a specific batch with a static contract address; we don't expect it to change for this repo.

Second best approach in my opinion is the suspense one, where we SSR the home page and stream the child client component using the suggested useScaffoldReadContract hook.

A fantastic pattern, definitely better than having no loading state then having layout shift as the data pops in (especially for larger streaming components, such as YouTube's homepage). If you don't want to go the viem route, this kind of approach is good enough.

What do you think, @All-Khwarizmi?

[derrekcoleman]

I appreciate the way you factored out the logic to keep things organized 👌

[derrekcoleman]

Did you know about the useScaffoldReadContract hook (docs)? I encourage you to try a quick refactor using it so you get some experience with one of Scaffold-ETH's most commonly used tools.

[All-Khwarizmi]

SSR.demo.mov

Thanks for the detailed feedback! I'd like to share the implementation journey as it demonstrates some interesting Next.js patterns:

1. Initial Streaming Implementation with Serialization
   I had an intermediary implementation that used Suspense boundaries to stream a client component that in turn rendered a server component:

// Home.tsx (Server Component)
<Suspense fallback={<LoadingCounter />}>
  <BuildersCheckInCount /> {/* Client Component */}
</Suspense>

// BuildersCheckInCount.tsx (Client Component)
"use client"
import { CounterDisplay } from "./CounterDisplay"; // Server Component!

function BuildersCheckInCount() {
  const { data: counter, isLoading, error } = useScaffoldReadContract({...});
  return <CounterDisplay data={counter} isLoading={isLoading} error={error} />;
}

This pattern technically bends Next.js rules by importing a Server Component into a Client Component, but works because:

• All props (counter, isLoading, error) are serializable
• The data flow is unidirectional (client → server)
• The Server Component is pre-rendered and its result is serialized for the client. Then when the data is available the component is hydrated.

Note: if you remove the suspense boundary the app would break!

2. Final SSR Implementation
   Given these observations, I opted for full SSR which offers several advantages:

• No loading states needed - better UX
• Lighter client bundle - better for mobile
• Simpler mental model - no serialization tricks
• Better performance as demonstrated in the video

I had to remove some utility functions (like bigint formatting) that weren't serializable, highlighting the constraints of this pattern.

The final implementation uses viem's createPublicClient directly on the server:

async function BuildersCheckInCount() {
  const publicClient = createPublicClient({...});
  const counter = await publicClient.readContract({...});
  return <CounterDisplay data={counter} />;
}

Rather than trying to bend the Next.js recommendations (which might quick turn into an anti-pattern), the full SSR approach provides better performance and maintainability while keeping the code straightforward.

Let me know if this reasoning makes sense or if you see other patterns worth exploring!