facebook / facebook/flow

Allow Ignore Refinement Invalidation checking for specified maybe variable/prop/member

Open
#5,614 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
Rust
Stars
22.3k
Forks
1.9k
PR merge metrics
No merged PRs in 30d

Description

_It would be great if_, in the [linked example](https://flow.org/try/#0PTAEAEDMBsHsHcBQiDG0CGBnToCCBlWFAawFMAXUAb0VFAH1Nz1zSAuUABlAB9QBGANy1QKWADsmAJwCuKcrCkAKAJTURdcgAsAlpgB0jZq1ABeLsLoBfZHSYtSqjtz79qoKRRlTxF0DboxcXFSeVV3bT1DexNzIX8RABM9IJCwtSpQSIMjBzM-ANAJJVIAN1Jxcg5pHXEAcwAaUQAjDgAxGXF5HQkMwswKxKUAW0w66vIpWrq+xBtUDGw8QhIKAFl0cXQ60il1OkYOAH4CIjJyYREg6TkFZQyNLN0DVNDyVRF5uj0AYQk01hDFQcZqwWDQUibfZ0UAgUAAB1grEqOnQ0GgAE9RLBhvCIQAPUBwOo6FCgJSYWCgAAiACUAJoqR6ecjeXwAQnZ2WioAAZLynlFGPoYqQzKY4pYEld-m9wjQYaAdJByVznvpfrL5KQgQ9FZp1Yx8iF4MszhRVFLFdzhcUAOTDUjYbakO1NcKmAB81CsKitMJtBntuykijd5LUXp9fpEcNAAD1RGjoEUVY7tLBEqAAAYSbP6UBrChaTNJ4JI0DNMUoZM6oq+RHYHTNTGgcQydGgUpomSkWNgBNJzuwNPF0u58T5wtjrM18uUKtDiFZiQI2BNltYzqJUiQWp17vQXuPQpfbHBN4AdUUxHQoe38seEMoOHMgf9cMRyPIqPRWLEuIEkSsAkmSSjNJ46DEDgdKMo8yqqjgPB8AYoqgOyEoCHq+qvm2pCmqcqzvDG+qgEG4hKA6TqYC64Yet6VC+v6dj6MGUihlIdGRgxTGPAaQq4Zg-qnrYoDJJgrzpNC3wqko3Kahe2q6tJAaGgY4mScRUpxomNbDqOGZZtmGlauQU5FoZZbiBWi56cu9Zrhurbtp2h7HnQOlLqmoDpiWRkmYpZkFhZflWTZ1a1iuDbrpgzattuu77lmbl9qRgb5Ale4hIkwmfKJAUAteUhkHesAPthgQSEwZH5O+jyfkiFQ-sm-44nipCEsSpLkhBkLQTSDJMoqCEUnyAqocYYoSnEFUwupKSmZafGCjkuGZUluXWHMiBAA), it was possible to tell Flow to trust that _maybe_ property `_s: ?ASocket;` will be managed by the user and therefore immune to `...possibly undefined/null value` errors due to _potential_ side-effects as explained in [Refinement Invalidations](https://flow.org/en/docs/lang/refinements/#toc-refinement-invalidations). It would be easy to have unit tests that cover this.

I completely get why this is done and the effect of side-effects and it is a great catch for potential errors. However, it would be nice to be able to ignore specific cases where the logic related to said property (or variable, etc) gets complex and where it makes more sense to practice DRY to prevent the spread of this logic throughout the code base. The latter IMHO would cause more potential for errors than possible side-effects.

So something like (`// $FlowIgnoreSideEffects` or `// $FlowIgnoreRefinementInvalidations`):
```js
// @flow

class ASocketManager {
_s: ?ASocket; // $FlowIgnoreSideEffects
...
}
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.