-
Notifications
You must be signed in to change notification settings - Fork 3
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
Conversation
06ea896
to
75c35f9
Compare
@@ -170,8 +152,8 @@ const Editor = ({ | |||
const handleReload = async () => { | |||
if (isCreateNewIndexer) { | |||
setShowResetCodeModel(false); | |||
setIndexingCode(defaultCode); | |||
setSchema(defaultSchema); | |||
setIndexingCode((formatIndexingCode(indexerDetails.code))); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 && ( |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
93d168b
to
0a87c56
Compare
@@ -91,28 +91,6 @@ const Editor = ({ | |||
localStorage.setItem(DEBUG_LIST_STORAGE_KEY, heights); | |||
}, [heights]); | |||
|
|||
// useEffect(() => { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@@ -14,14 +14,9 @@ export const ForkIndexerModal = ({ registerFunction, forkIndexer }) => { | |||
setIndexerConfig, | |||
isCreateNewIndexer, | |||
} = useContext(IndexerDetailsContext); | |||
const [indexerConfig, setIndexerConfigField] = useState({ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
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.
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.