Search Box v1

[saimeunt]

Search Box v1

⚠️ Reading contributors guidelines to get assigned is MANDATORY!

Read contributors guidelines

User stories

As a user, when I paste an Address / Txn Hash / Block / Token in the search bar, I want to see a list of corresponding exact matches in a combobox, with the proper category displayed (Block / Transaction / Address).
When I click on a result, I want to be redirected to the detailed page of the resource.

Validation

The end result should look like the Etherscan search box:

As it is a v1, we want to keep it simple so no extra work on the UI is needed beyond what can be achieved with shadcn/ui combobox.

Implementation details

For the time being, we will validate client side the type of the input box (one of block number / tx hash / address) and display only one exact match result.
If the input is a block number, call getBlock to validate and display a result with a link to the block /block/:number.
If the input is a tx hash, call getTransaction to validate and display a result with a link to the tx /tx/:hash.
If the input is an address, call isAddress to validate and display a result with a link to the EOA/contract /address/:address.

Resources

• • shadcn/ui combobox: https://ui.shadcn.com/docs/components/combobox
• getBlock: https://viem.sh/docs/actions/public/getBlock
• getTransaction: https://viem.sh/docs/actions/public/getTransaction
• isAddress: https://viem.sh/docs/utilities/isAddress

[Iwueseiter]

Hi @saimeunt can I work on this? I'm a frontend developer, I'm good with Tailwind CSS,React and TypeScript and will deliver the search box as expected between 2 to 3 days.
Here is a link to my onlydust profile: https://app.onlydust.com/u/Iwueseiter

[Shoetan]

Hi @saimeunt I think I can work on this. I have implemented user interfaces before. I will first install the combo box using shadcn and create the search component.

From the input determine if the input is a block number, txhash or an address(i.e validating the type of input on the client side) Txhash are very long made up of hex characters, block id are number like 1234567 while an address is alpha-numeric and starts with a specific prefix for networks.

This will help me determine which of the viems public actions to use. Then call the viem public action in the chains.tx file.

Set up routing using router.push in next js.

https://github.com/Shoetan

[Benjtalkshow]

Hi, @saimeunt

I'm interested in developing the Search Box for the Op Scan. This is my first time contributing to a Walnut project as I wasn't opportune to get any frontend tasks in ODHack 4.0. With my solid background in Next.js, TypeScript, Shadcn, and React, I’m confident in delivering an efficient and user-friendly search functionality. You can check out my Github profile here: https://github.com/Benjtalkshow.

Here is how I will implement my code:

I will create the components/SearchBox.tsx for the search component and design the UI using Shadcn for responsiveness and accessibility. I'll implement Next.js API routes in pages/api/search.ts for search queries, and validate client-side input types (block number, tx hash, or address) using getBlock, getTransaction, and isAddress. Based on the validation, I will link to the appropriate detailed page. I'll include features like auto-suggestions, recent searches, and error handling to improve usability, ensuring real-time, accurate search results and a smooth user experience across all devices.
Give me a chance to showcase my skill with this project.

[bhavyagosai]

hey Bhavya here! I have been working with frontend development for almost 2 years now. This issue seems very interesting to work on as it involves determining what input the user has put and implementing logic accordingly! I would love to add this feature if thats okay!

To solve this issue I would

• determine whether the input string is a block, a transaction id, an address, or something else entirely and display results accordingly

• For determining a simple approach would be a trial and error method where we trigger api one by one and check if the response is getting received which is not at all a good approach.

• Ideally what we can do is check if the string is starting with a 0x; thus determine if the string is a hexadecimal and rule out if its a block (because blocks are generally integer values with being much shorter in length)

• If they are hexadecimal values, we can check for length and determine.

  • transaction hash are usually 66 digits long with a 0x prefix.
  • ethereum addresses are usually 42 digits long with a 0x prefix.
  • also addresses can be checked using isAddress() function from viem

• Thus the type of string entered can be determined using this logic and correct labels can be displayed in the combobox.

• Upon clicking/hitting enter, correct redirection can be made according to the above logic.

• If this logic is applied, I dont feel there will be a need to do a getBlock() or getTransaction() api call, as upon redirection, the api call will already happen on the destination page, either /block/:number or /tx/:hash or /address/:address. And non existing data would be handled at the page level itself. I might be wrong here but just throwing out ideas!

[jedstroke]

Hello Walnut Fam,

I am a seasoned fullstack developer with a focus on front-end development. Although I haven't contributed to Walnut before, I am excited by your welcoming stance: "However, if you are new, don’t worry—we are eager to attract new talent..."

I am passionate about creating responsive, modular, and scalable UI components and would love to take on this issue.

Here are my profiles for your reference:

• OnlyDust: Jedstroke's Profile
• Portfolio: Jedidiah Gabriel
  Looking forward to contributing!

Best regards,
Jedidiah Gabriel

[Dprof-in-tech]

Hello! I am Isaac. I've been working with frontend development technologies for over 2 years now and would love to work on this issue.

Here's how I propose to solve this issue:
I plan to determine whether the input string is a block number, transaction ID, address, or something else, and display labels for the results accordingly. Instead of using a trial-and-error method with multiple API calls (which wouldn't be efficient), I have a more optimized approach in mind:

First, I'll check if the string starts with '0x' to identify hexadecimal values. This would rule out block numbers, which are typically shorter integer values.
For hexadecimal values, I'll use the string length to categorize:

Transaction hashes are usually 66 characters long (including the '0x' prefix)
Ethereum addresses are typically 42 characters long (including the '0x' prefix)
I can also use the 'isAddress()' function from 'viem' to verify Ethereum addresses

Using this logic, I can determine the type of string entered and display the correct labels in the combobox.
I would use the correct API call method to get the exact match for the use input while assigning the correct label deduced using this logic.

When the user clicks or hits enter, I'll implement the correct redirection to the correct resource endpoint.

I believe the best way would be to add the label to the user search input but perform the API call on page level after the user has navigated to the page by using the provided input gotten from the URL as a search parameter to perform the API call usingthe appropriate caller function.

I believe this approach should provide a smooth user experience while being efficient on the backend. Of course, I'm open to any feedback or suggestions to improve this implementation!

Let me know if you'd like me to proceed with this solution. I'm looking forward to contributing to this project!
here are the links to my onlydust profile

https://app.onlydust.com/u/Dprof-in-tech

Thanks

[armandocodecr]

Request for Assignment: Search Box v1 Issue

Hello Walnut team,

My name is Armando, and I am interested in working on the Search Box v1 issue. I have experience in developing with Next.js and React, and I believe I can effectively contribute to solving this problem.

Plan to Resolve the Issue

To implement the search box functionality, I will follow an approach that prioritizes efficiency, clarity, and simplicity. Below are the steps I will take:

Implementation of the Search Component

• I will use the Combobox component from shadcn/ui to create the search box. This component provides an intuitive and manageable user experience, aligned with modern UI standards.

Performance Optimization with Debounce

• I will incorporate a debounce mechanism to control API requests based on user input. This means that the API request will only be made after the user has stopped typing for a short period (e.g., 500 ms). This technique will prevent sending multiple requests while the user is typing rapidly, optimizing performance and reducing server load.

Input Type Detection and Validation

• I will implement logic to identify the type of input provided by the user (block number, transaction hash, address, or token) as follows:
  • Block Number: Detected if the input is a numeric value within a valid range for block numbers.
  • Transaction Hash: Identified by its characteristic length and hexadecimal pattern.
  • Address: Recognized by its standard Ethereum address format (40 hexadecimal characters).
  • Token: I will use additional logic or API checks to verify if the input corresponds to a token, possibly involving a pattern match or a call to a token registry API.

Based on the detected type, the input will be validated:

• Block Number: Validated using getBlock and displaying the result with a link to the block details.
• Transaction Hash: Validated using getTransaction and displaying the result with a link to the transaction details.
• Address: Validated using isAddress and displaying the result with a link to the address details.
• Token: Validated using token-specific checks and displaying the result with a link to the token details if applicable.

Presentation of Results

• I will configure the Combobox to display the search results in a dropdown list. Each list item will clearly indicate the category (Block / Transaction / Address / Token) and will redirect the user to the appropriate detail page when clicked.

Why This Solution is Optimal

1. Performance Efficiency: The debounce implementation minimizes unnecessary API requests, improving application efficiency and reducing server load.
2. Clarity and Usability: Using the shadcn/ui Combobox ensures a clean and user-friendly interface, aligned with the search experience on Etherscan.
3. Comprehensive Input Handling: The input type detection and validation logic ensures accurate identification and handling of various input types (block number, transaction hash, address, token), making the search box robust and versatile.
4. Flexibility and Extensibility: This approach allows handling different types of input data clearly and scalably, facilitating future extensions or modifications.

I hope my proposal aligns with your needs. I am available to discuss any aspect of the plan and adjust it as necessary to fully meet the team's expectations.

Thank you for considering my request.

Best regards,
Armando
My OnlyDust Profile

[Benjtalkshow]

Hello @saimeunt,

I'm interested in implementing the Search Box for the Op Scan Project. This is my first time contributing to a Walnut project. With my 3 years of solid background in Next.js, TypeScript, Shadcn, and React, I’m confident in delivering an efficient and user-friendly search functionality. You can check out my GitHub profile here: https://github.com/Benjtalkshow. This is my second comment on this issue, demonstrating my keen interest in tackling it.

Proposed Solution for Search Box v1

• I will create a new component called SearchBox in src/components/SearchBox.tsx, using Shadcn's combobox to ensure the search bar is simple and intuitive, mimicking the Etherscan search box.
• I will implement client-side validation to determine if the input is a block number, transaction hash, or address. For block numbers, I will use getBlock to validate and display a result linking to /block/:number. For transaction hashes, I will use getTransaction to validate and display a result linking to /tx/:hash. For addresses, I will use isAddress to validate and display a result linking to /address/:address.
• I will implement real-time suggestions to display exact matches in the search combobox, categorized as Block, Transaction, or Address. When a user clicks on a search result, they will be redirected to the corresponding details page of the resource.
• I will design the search box to work seamlessly across all devices and thoroughly test the component across different browsers and screen sizes to ensure consistent behavior and user experience.
• For the UI, I will use Shadcn Combobox.
• For validation, I will use getBlock, getTransaction, and isAddress.

[saimeunt]

Wow a lot of very good comments on this one, thank you everyone for your interest.
I'll pick @armandocodecr as he really went in great details on how he plan to address the issue, good luck!
Other contributors: there will be more issues in the coming days, stay tuned!