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

Element type should always match the expected type #1121

Closed
3 tasks
theKashey opened this issue Dec 11, 2018 · 2 comments
Closed
3 tasks

Element type should always match the expected type #1121

theKashey opened this issue Dec 11, 2018 · 2 comments
Milestone

Comments

@theKashey
Copy link
Collaborator

Element type should always match the expected type. Some approaches wrap component types but this can break .type === MyThing. This is a common source of bugs and should not happen.

With option ignoreSFC any SFC would be compliant to this principle, but class components would not. Option to do the same for components - ignoreComponent, is not the same - it would preserve old class instance, and literally disable hot loading.

Without this option class component would we wrapped with a proxy to maintain req equality. Which makes super hard (impossible for current code base), to actually change class link and force remount, if RHL could not reply necessary changes - see #1024, this is something we have to have.

Proposal

Allow RHL to land patches directly on class component - it has the power to change prototype, and already doing it to bypass babel inheritance checks.

Result: classes are not wrapped with proxies, <Class/>.type === Class, and we able to control remount via hotComparison hook.

Minus: we should hot update all "versions" of mounted components. That's not a problem, as long this tracking already exists.

This would give us more than one principle:

  • Element type should always match the expected type.
    We are not changing any type and not wrapping anything in proxies.
  • It is better to lose local state than to behave incorrectly.
    We are able to drop old version
  • Discard state when it’s clear the developer wants to.
    We are able to drop old version
@theKashey
Copy link
Collaborator Author

Superseded by #1261

@theKashey
Copy link
Collaborator Author

Released in v4.11.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant