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

Support registry delete returning update function #2020

Merged
merged 6 commits into from
Oct 20, 2019
Merged

Conversation

guybedford
Copy link
Member

@guybedford guybedford commented Sep 3, 2019

With this API the registry delete function will return an update function that can be called later on once the module is reimported.

When that happens, any modules that previously depended on the deleted module will get rebound to the new module, effectively using ES module live bindings to do this.

The has API function is also updated to return true on in-progress loads.

Will be useful for fully-live hot reloading workflows, as in #2014.

src/features/registry.js Outdated Show resolved Hide resolved
src/features/registry.js Show resolved Hide resolved
@LarsDenBakker
Copy link
Contributor

LarsDenBakker commented Sep 7, 2019

I've rebased #2014 on this. One questions I still have:

Previously we updated dependents' references to the reloaded module. None of my tests are failing without it, should we leave this part out? We need a reference to the load wrapper in order to do this.

@LarsDenBakker
Copy link
Contributor

I found another scenario we need to account for.

If module a has an execution error we don't return an update function. This might be ok if the error is on the initial load, but if the module goes from success -> error -> success we lose reference to the original importSetters.

Similarly when a module reloads that has an update function and it failed to execute we don't update the importSetters either, so we lose that information for the next reload.

Co-Authored-By: Lars den Bakker <larsdenbakker@gmail.com>
@guybedford
Copy link
Member Author

Previously we updated dependents' references to the reloaded module. None of my tests are failing without it, should we leave this part out? We need a reference to the load wrapper in order to do this.

You mean the reference in the load dependencies? That isn't used after execution, so should be fine.

If module a has an execution error we don't return an update function. This might be ok if the error is on the initial load, but if the module goes from success -> error -> success we lose reference to the original importSetters.

Similarly when a module reloads that has an update function and it failed to execute we don't update the importSetters either, so we lose that information for the next reload.

Can we not keep the previously working update function around in these case when using the API? That is only apply the update function when the module is known to have executed successfully, and otherwise keep it around until it does.

@LarsDenBakker
Copy link
Contributor

That might work indeed, I will try it out.

@guybedford
Copy link
Member Author

I've added a commit here to handle the System.set issues discussed in #1976.

@khangsfdc
Copy link

@guybedford can you explain the rational for changing System.has to return true for in-progress changes?

Prior to that change System.get and System.has returned the same values, after the change, only has returns true for in-progress modules.

@guybedford
Copy link
Member Author

@khangsfdc hmm that sounds weird to me... maybe we should reconsider it?

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.

4 participants