refactor(shared): improve flowtype

[kazupon]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
• All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
• New/updated tests are included

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

[nickmessing]

Does this affect anything?

[kazupon]

I don't think there is any problem. 🤔
In fact it can return various types of values.

case1: Regex

vue/src/compiler/parser/text-parser.js

Line 9 in e259fc3

const buildRegex = cached(delimiters => {

case2: Object

vue/src/platforms/web/util/style.js

Line 5 in 30258a9

export const parseStyleText = cached(function (cssText) {

[yyx990803]

Hmm, I personally don't like annotating variable declarations when it is obvious enough. Flow is also smart enough to infer these cases I believe. It's more valuable to annotate function arguments because those are not immediately obvious when the definition of the function is separate from the call site.

[HerringtonDarkholme]

Hi @kazupon. As far as I know, most languages prefer inference over annotation, at declaration site.

The reasoning for inference:

1. type is already obvious and explicit from initializer, e.g. parseFloat, isObject is very clear.
2. additional annotation is duplication. If we later want to change initializer, we have to also change annotation.
3. annotating everywhere can make reader confused. Readers might think universal annotation is code authors' quirk so no more info brought by annotation. But some annotations do have some useful information. Consider code let i: Context = {}; i.field = fieldInfo; and let i: number = 42. The former annotation does express additional information.

There is also good advice for when to add annotation, though in scala (we can skip scala specific rule like implicit).
https://github.com/databricks/scala-style-guide#type-inference

[kazupon]

@HerringtonDarkholme
Thank you for great explanations!
Indeed.

I seemed to have been lack of knowledge about type annotation names yet.
I close this PR.
Sorry for confusing you. 🙇