Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DPLT-1034 feat: allow to edit indexer when forking #127

Merged
merged 2 commits into from
Jul 14, 2023

Conversation

roshaans
Copy link
Contributor

@roshaans roshaans commented Jul 13, 2023

While forking an indexer, you'll be given the chance to change the schema + indexerLogic before publishing.

When forking, we also update the indexer_name and account_name of the mutations and queries the new forked indexer targets.

-- What we do in this PR
Prior to this PR, the concept of forking an indexer(your own vs someone elses) or
publishing an indexer(creating a new indexer vs publishing code to an existing indexer) were very confusing.

With this PR, we separate the responsibilities to make it more clear. With that change, there is no concept of having an indexerConfig while forking an indexer as the only information we ask the user in the modal is about the new indexerName they would like to set.

In the background, we use the indexerConfig of the indexer the user forked.

@roshaans roshaans force-pushed the feat/edit-before-fork branch from 06ea896 to 75c35f9 Compare July 14, 2023 16:51
@@ -170,8 +152,8 @@ const Editor = ({
const handleReload = async () => {
if (isCreateNewIndexer) {
setShowResetCodeModel(false);
setIndexingCode(defaultCode);
setSchema(defaultSchema);
setIndexingCode((formatIndexingCode(indexerDetails.code)));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When reloading, if you have forked an indexer, then it will reload the forked indexer rather than the default code.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a pretty nice change!

@@ -72,7 +72,7 @@ const EditorButtons = ({
<Breadcrumb.Item className="flex align-center " href="#">
{accountId}
</Breadcrumb.Item>
{!isCreateNewIndexer && (
{indexerName && (
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when you have a forked Indexer, it has a indexerName. We want to show the indexerName as part of the breadcrumb paths.

But when we are creating a new indexer, it is fine not to show any breadcrumbs.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is a Breadcrumb in this case?

Copy link
Contributor Author

@roshaans roshaans Jul 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Those are breadcrumbs. Weird name haha

@roshaans roshaans force-pushed the feat/edit-before-fork branch from 93d168b to 0a87c56 Compare July 14, 2023 16:59
@roshaans roshaans marked this pull request as ready for review July 14, 2023 17:00
@roshaans roshaans requested a review from a team as a code owner July 14, 2023 17:00
@roshaans roshaans changed the title feat: allow to edit indexer when forking DPLT-1034 feat: allow to edit indexer when forking Jul 14, 2023
@@ -91,28 +91,6 @@ const Editor = ({
localStorage.setItem(DEBUG_LIST_STORAGE_KEY, heights);
}, [heights]);

// useEffect(() => {
Copy link
Collaborator

@darunrs darunrs Jul 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commented code seems to be doing something useful, checking for too large block heights. Is this code implemented elsewhere or do we not need to do this check anymore? Also the code on line 24 and 43 may not be needed since they reference things that are only present in the code being removed. Unless they're used by another class somewhere else. Also, given that this code is in FrontEnd, would it be worth it to add unit tests which pass in valid and invalid block heights?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We used to have a limitation in the number of blocks we would allow to be historically indexed. As a result we showed error messages if the user's set the block height prior to what our limit at that time was. I believe it was an hour or 3,600 blocks.

We have removed this limit now, and this code is not going to be needed anymore.

@gabehamilton thought that the relative block heights that we provided were quite helpful, so we still provide some helpful information regarding setting block height in this modal.
image

@@ -14,14 +14,9 @@ export const ForkIndexerModal = ({ registerFunction, forkIndexer }) => {
setIndexerConfig,
isCreateNewIndexer,
} = useContext(IndexerDetailsContext);
const [indexerConfig, setIndexerConfigField] = useState({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that most of this part of the cleanup was removing the indexerConfig object. What was the purpose of the object before and why is it not necessary anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prior to this PR, the concept of forking an indexer(your own vs someone elses) or
publishing an indexer(creating a new indexer vs publishing code to an existing indexer) were very confusing.

With this PR, we separate the responsibilities to make it more clear. With that change, there is no concept of having an indexerConfig while forking an indexer as the only information we ask the user in the modal is about the new indexerName they would like to set.

In the background, we use the indexerConfig of the indexer the user forked. This makes things much more clear.

Copy link
Collaborator

@darunrs darunrs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple clarification questions and nitpicks but it LGTM otherwise.

@darunrs darunrs self-requested a review July 14, 2023 17:58
Copy link
Collaborator

@darunrs darunrs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@roshaans
Copy link
Contributor Author

LGTM

Thank you. Moving forward, it will probably be really helpful to have a dev environment be automatically be created to test the changes in a PR. I'll look into how to do that.

//
// if (height - blockHeight > BLOCKHEIGHT_LIMIT) {
// setBlockHeightError(
// `Warning: Please enter a valid start block height. At the moment we only support historical indexing of the last ${BLOCKHEIGHT_LIMIT} blocks or ${BLOCKHEIGHT_LIMIT / 3600
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code that is not needed anymore.

@roshaans roshaans requested a review from morgsmccauley July 14, 2023 18:22
@roshaans roshaans merged commit e9b66cc into main Jul 14, 2023
@roshaans roshaans deleted the feat/edit-before-fork branch July 14, 2023 20:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants