introducing explorer v0.1

[armsves]

This is the first implementation of the Yellow Explorer for State channels
Initially it's using the Blockscout frontend but I would prefer to rewrite a less cluttered version of the frontend keeping the visual aesthetics.
TODO:
redo frontend and use redux, fix the seach bar and links.
each box should lead to the TX that opened/closed the channel in the chain's explorer
for the cron-job:
improve the periodic calls to the wss but that also means that the endpoints needs to be updated for pagination and to respond with latest content with page or id.

for now these are the changes I remember that needed to be done but I will expand once I check again!

[gemini-code-assist]

Hello @armsves, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Gemini has reviewed this pull request. The main purpose of this PR is to introduce the initial version (v0.1) of the Yellow Explorer for State channels into the repository. Based on the changes, this is achieved by integrating the explorer project as a git submodule. The pull request description indicates that this initial version uses the Blockscout frontend, with future plans to rewrite the frontend for a less cluttered look and improve the data fetching mechanisms.

Highlights

• Feature Introduction: This pull request introduces the Yellow Explorer feature for State channels.
• Git Submodule Integration: The explorer project is integrated into the main repository as a git submodule, specifically pointing to commit b0530c96088d832b632412843e7dc94ad762296b.
• Initial Frontend: According to the description, the initial implementation utilizes the Blockscout frontend, with a custom rewrite planned for the future.

Changelog

• explorer
  • Added/updated the explorer git submodule to commit b0530c96088d832b632412843e7dc94ad762296b.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces the Yellow Explorer v0.1 by adding it as a submodule. This is a commendable first step towards establishing the explorer functionality.

However, to ensure clarity, reviewability, and a shared understanding of this initial version, a few points should be addressed:

1. Submodule Change Context: The PR updates the explorer submodule to commit b0530c96088d832b632412843e7dc94ad762296b. It's crucial to provide context for these submodule changes, such as a summary or a link to the submodule's own PR/commit details.
2. Scope of v0.1: The description lists significant TODOs. Clarifying which of these are out of scope for this v0.1 release and what core functionality is expected to be operational would be beneficial for setting expectations.
3. Testing Information: Details about the testing strategy (e.g., unit, integration, E2E tests) for this new component would help in assessing its current stability and reliability.

Addressing these aspects will significantly improve the quality of this contribution and facilitate a more thorough review process.

Summary of Findings

• Lack of Context for Submodule Update: The PR updates the explorer submodule to commit b0530c96088d832b632412843e7dc94ad762296b. For better reviewability and traceability, it's important to provide a summary of the key changes included in this submodule update or link to its corresponding PR. This was raised as a review comment.
• Clarity on v0.1 Scope vs. TODOs: The PR description lists significant TODOs (e.g., frontend rewrite, fixing search/links, improving cron-job). For a 'v0.1' release, clarifying which functionalities are complete and what is deferred helps set proper expectations for the current state of the explorer. This was not made as a line comment as it's a general concern about the PR's scope rather than a specific line of code changed, but it's a medium concern for project clarity.
• Testing Strategy for Explorer v0.1: Information on the testing approach (e.g., unit, integration, E2E tests) for this new explorer component is missing. Understanding the testing strategy is crucial for assessing the reliability and stability of this initial v0.1 release. This was not made as a line comment as it's a general concern about quality assurance rather than a specific line of code changed, but it's a medium concern.

Merge Readiness

This pull request marks an important step by introducing the Yellow Explorer v0.1. However, based on the review, there are several medium severity concerns that should ideally be addressed before merging to ensure clarity and maintainability:

1. Context for Submodule Changes: The primary change is a submodule update to commit b0530c96088d832b632412843e7dc94ad762296b. More details on what this commit entails are needed.
2. Scope Definition for v0.1: Given the extensive list of TODOs, a clearer definition of what constitutes the deliverable for v0.1 is recommended.
3. Testing Information: Information about how this new component has been or will be tested is currently absent.

It is recommended that these points, particularly providing context for the submodule changes and clarifying the scope of v0.1, be addressed. As a reviewer, I am not authorized to approve pull requests. Please ensure this PR undergoes further review and receives approval from other designated team members before merging.

[akushniruk]

@armsves
Thank you for your pull request. We will not merge it right away; instead, we will split it and rework the frontend, as we don't need the Blockscout frontend and can do it more simply.