fuellabs / fuel-explorer Goto Github PK

On the contact page, on the tab source code, the user should be able to visualize the bytecode of the contract and abi and function signatures.

Right now, the only available data is the contract bytecode.
Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72599&mode=design&t=QvLFwOte6x138asK-4

some extra right space when using Iphone 12 in chrome inspector

problem happens when you are in a popup. If you remove the blur you can see the background layout is broken

issues with the QA Deployment

Transaction popup

• Big texts can break the UI
• Increase size of table, its too tight

Transaction List

• Loader its weird, one element comes, then others. needs to be clean
• When the "Action Required" is on the list, the "days left" text gets disaligned

FRO-30

The client may contain the following information inside a block

Querying a block should contain the following

• Block height
• Previous block hash
• Time
• List of transactions

When a transaction has input message, the page not show the input because incorrect data is being returned from grouped inputs.
https://fuel-explorer.vercel.app/tx/0xb09451bce1549f2e2f86009a64e385ce8b45e5e2d71ecdad5f37a910640432e2

• This is a tracking issue for the block explorer project
• The expectation is that this issue will be a container issue for smaller more actionable work, to be listed below
• This list will evolve over time, feel free to add new issues/categories as you see fit

Frontend

• [ ] #7
• [ ] #8
• Fronted stuff tracked in Linear

Indexer

• FuelLabs/fuel-indexer#656
• FuelLabs/fuel-indexer#637
• FuelLabs/fuel-indexer#646

Ops/Infra

• #9
• #6

FRO-33

Enable fetch by account;

• Balances
• Coins
• Messages
• Transactions

• This is a follow up to https://github.com/FuelLabs/block-explorer-backend/issues/4
• After we have our data models we'll need to write the actual indexer modules that will index events
• Similar to https://github.com/FuelLabs/block-explorer-backend/issues/4, @luizstacio on @FuelLabs/frontend has mentioned that his team will take the initial stab at writing these, and @FuelLabs/indexer will provide review/support
• We will need to version these assets and store them in a particular location for archiving purposes
  • Sure the DB can act as a sort've archive, but I think we might want to also archive in git

FRO-29

Fetch a single TX should fetch all the fields available on the TX this is one example https://gist.github.com/luizstacio/44bda679b8805bbb835370f839855227

The contract page is a group of tabs with a brief contract summary. On this task, we should create only the header and the tabs for later adding the contents on the following tasks.

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72599&mode=design&t=QvLFwOte6x138asK-4

Pair programming with me to do this and we can record the call to serve as material for other devs later

On the account page predicate tab, the user should be able to see a predicate's bytecode, abi, and signature. We should add a bytecode because we don't have predicate metadata yet.

We should not show the tab predicate if the address is not a predicate.
To know if an address is a predicate, we need to check inside the transaction history of the address and see if an input of type Coin, with the same address, contains a predicate, if yes address is considered a predicate. The bytecode to be shown is this predicate bytecode. This can be done on the GraphQL side and returns only the data in a structured way to the FE side.

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72528&mode=design&t=QvLFwOte6x138asK-4

FRO-26

Enable users to list all transactions with;

• Tx ID
• status
• Age
• Address involved
• From
• To

Currently we use createComponent as a base to enable a better development experience when developing the components for the UI library. But we notice that it creates some issues of performance that block the execution of the component.

This could be leading too many other issues like the problem where the components are not responsive for couple of milliseconds before render. By removing this from the root component it reduced a lot as the wrapper components if not well optimized can lead to multiple re-renders of all children components.

The use case to see the issue was the change on the Theme component. That was causing a issue where the theme was only loaded after couple of milliseconds (~1s) that was perceptible for the user.

The code for the theme previously using the createComponent was:

export const Theme = createComponent<ThemeProps, typeof RadixTheme>({
  id: 'Theme',
  baseElement: RadixTheme,
  render: (
    Comp,
    { iconSize = 20, iconColor = 'text-current', iconStroke = 1.2, ...props },
  ) => {
    return (
      <IconProvider
        value={{ size: iconSize, color: iconColor, stroke: iconStroke }}
      >
        <Comp {...props} />
      </IconProvider>
    );
  },
  defaultProps: {
    grayColor: 'slate',
    accentColor: 'grass',
    appearance: 'dark',
    radius: 'medium',
    panelBackground: 'translucent',
    scaling: '105%',
  },
});

And the version there is currently working that solved the issue looks like this;

    <RadixTheme>
      <IconProvider
        value={{ size: iconSize, color: iconColor, stroke: iconStroke }}
        {...props}
      >
        {children}
      </IconProvider>
    </RadixTheme>

• Purge the use of fuel-ui packages
• Update styling of the UI packages
• Render bridge and ecosystem pages using next.js

This one goes in the same PR of #186

Description

As a developer actively working with the Fuel Network, I believe there is a significant need for a new blockchain explorer with enhanced features and a user-friendly interface, inspired by platforms like BlockScout.

Key Features Requested

1. Developer-Friendly API: Ensure the availability of a well-documented and accessible API for developers to integrate with the explorer.
2. Rich Transaction Details: Comprehensive information about transactions, blocks, and addresses for thorough analysis.
3. Smart Contract Support: Robust integration for displaying details about tokens and smart contracts on the Fuel Network.
4. Extensible Architecture: Develop the explorer with scalability and extensibility in mind to accommodate future enhancements.

Technical Considerations

1. Preferred Technology Stack: If you have specific preferences for the technology stack, please mention them here.
2. Open Source Contributions: I encourage the project to be open source, allowing the community to contribute and improve the explorer.

Purpose of the Request

The development of a new blockchain explorer is crucial for the developer community to enhance their experience when interacting with the Fuel Network. This will contribute to a more vibrant and engaged ecosystem.

Timeline and Collaboration

I would appreciate insights into the expected development timeline and whether there is an opportunity for community collaboration in this project.

This one goes in the same PR of #186

• This is a follow up to https://github.com/FuelLabs/block-explorer-backend/issues/3
• I know we have various methods of monitoring prod failures (e.g., Slack pings)
• Outside of the scope of ops monitoring, this issue is with regard to just general performance monitoring. Things like:
  • Requests to GraphQL API
  • Requests to fuel node (responses from Fuel node)
• The basic gist is, outside of ops/infra context (i.e., "Is this thing up and running?") it would be nice to know how the service is actually performing .
  • This will help us diagnose potential issues (e.g., resource saturation and such)

FRO-28

The coins list should return;

• UTXO id
• Amount
• Age

• We will need a deployment for the block explorer
• Since the block explorer will just be a big indexer, the deployment can look almost exactly like the fuel-indexer deployment
• We should be able to merge to master and have a new deployment triggered

We can create grap the important operations to show on the execution stack using the receipts returned when querying a transaction: https://gist.github.com/luizstacio/a5e51705a8965a3ece87cea90981fa15

https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72095&mode=design&t=inZn0sqONx8oxahO-4

The Dockerfile was unable to find / install curl / zip when the commands are RUN separately.
The start.sh script had a syntax error on the function.

The advanced tab should show the following;

• The raw payload of a transaction;
• And the whole query from the transaction in JSON. The JSON should be only the transaction, not the props from the GraphQL.

GraphQL query: https://gist.github.com/luizstacio/a5e51705a8965a3ece87cea90981fa15
Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72541&mode=design&t=QvLFwOte6x138asK-4

FRO-25

User Story: As a developer, I shall have a GraphQL schema generator implemented on the indexer API to enable dynamic fetch schema generation and custom types implementation.

Acceptance Criteria:

1. Implement a dynamic fetch schema generator within the indexer API, which enables the use of codegen-graphql.
2. Develop a plugin for codegen-graphql that allows the implementation of custom types from the indexer.
3. Leverage a PostgreSQL GraphQL library to fetch the structure from PostgreSQL and interpret primitive types to the types from the type schema created in the index project.

this issue intents to test if all the flow works well even with contracts (eth and fuel side) of different decimal config than the regular ones

The account page is a group of tabs that show predicate, assets, and history. This task should create the main page with the tabs for later adding the content.

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72503&mode=design&t=QvLFwOte6x138asK-4

When the user sees a contractId on the application, he should be able to click on the contract and go to the contract page.

The advanced view of a block should show the whole query from the block including the transactions (id, type, timestamp, and status) in JSON. The JSON should be only the block, not the props from the GraphQL.

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72552&mode=design&t=S2Jr6aSBRekhoQju-4

On the asset page account, the user should be able to visualize all the assets he has grouped by assetId and with UTXOs on the toggle when the asset is expanded. For this part, we can use the assets in the Transaction.

The NFT would be done after, as the data to support it is unavailable yet.

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72500&mode=design&t=QvLFwOte6x138asK-4

On the contact page on the balances tab, the user should see all the balances a contract holds. The assets should use the same components as the assets of the user, which means summarize by assetId, in this case, contract balances don't have UTXOs. This way, we can remove the toggle option.

To query the contract balances we can use: contractBalances

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72575&mode=design&t=QvLFwOte6x138asK-4

Explore if we can include Vitest (use PR from Pedro, message him to info)

We already have an Asset component but I think it's not fully usable, need to check and update it to be able to use it across the project. Also integrate it with the new @fuels/asset package.

ProductName: macOS
ProductVersion: 14.3.1
BuildVersion: 23D60
Google Chrome: Version 122.0.6261.69 (Official Build) (x86_64)

While the Bridge is in the settlement phase (shown above) or the Confirm transaction phase while it's open and on the screen, it's using so many of my machine's resources that Chrome becomes unusable and eventually the whole machine becomes unusable.

Let me know if you need more information.

FRO-34

User Story: As a developer, I want to create an infrastructure that allows testing the block explorer and automating these tests on the CI pipeline to ensure consistency and quality.

Acceptance Criteria:

1. Set up a testing environment for the block explorer, including the required services and dependencies.
2. Create and maintain a comprehensive suite of tests for the block explorer for end-to-end tests.
3. Integrate the testing suite into the CI pipeline to run tests automatically on each PR.
4. Provide clear and concise reporting of test results and failures, allowing developers to identify and fix issues quickly.

Additional:

1. We can use either TypeScript or Rust to write the end-to-end tests.
2. As we aim to do E2E, the tests should spin up an indexer linked to a fuel-core with data pre-loaded and then execute all queries.

The block page is a group of tabs with a brief summary of the block. On this task, we should create only the header and the tabs for later adding the contents on the following tasks.

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72545&mode=design&t=S2Jr6aSBRekhoQju-4

FRO-27

• Height
• Txs
  • Id
  • Age
  • Status
• Producer Address

we keep getting this screen sometimes

two situations I was able to simulate:

• being on bridge, and click on "explorer" link on menu
• being on explorer home, and click on first "mint" transaction of the list

FRO-35

User Story: As a developer, I want to create a reliable and scalable infrastructure for the live block explorer indexer, ensuring that it processes and indexes blockchain data efficiently and effectively.

Acceptance Criteria:

1. Set up a production-ready environment for the block explorer indexer, including necessary services and dependencies.
2. Ensure that the infrastructure is scalable to handle increased data loads and traffic as the blockchain grows.
3. Implement monitoring and logging solutions to track the performance and health of the indexer, enabling quick identification and resolution of issues.

The account page transactions tab should show the users all the transactions made by the user, sorted by the newer ones to the old ones. Once the user clicks on the transaction, it should open the transaction page.

Notes;

• Fuel-core returns the transactions from an owner out of order, we can sort the data on the GraphQL side.
• Fuel-core does not support pagination on the transactions by owner we could right now, just return the first 200 transactions.

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2068-72496&mode=design&t=QvLFwOte6x138asK-4

• We will need data models defined GraphQL schema as the first step in writing an indexer (or indexers) for this block explorer
• Here is an example of the type of GraphQL schema I'm referring to
• @luizstacio on @FuelLabs/frontend has mentioned that his team will take responsibility for writing the initial schema and @FuelLabs/indexer will review/approve
• From there, we can get started writing indexers

On the block page, transactions tab, the user should see a list of the transactions in the block.

• Pagination is not required as we currently do not have support for pagination on the inner data of a block.
  We should query just the minimal info required to display on the list to avoid the query failing, as a block can contain multiple transactions with lots of data.
• When clicking on a Transaction Item, it should open the transaction page.

Design: https://www.figma.com/file/VTWcuPxsUtKZDk0iKn3y7T/Fuel-Portal-Product-Board?type=design&node-id=2529-37680&mode=design&t=S2Jr6aSBRekhoQju-4

FUEL_PROVIDER
FUEL_PROVIDER_URL

unify them to use only the

NEXT_PUBLIC_FUEL_CHAIN

then get the URL from there