Actually Style.t is used for everything, so aviewStyle is at, andarray(...) is t too, same forarrayOption. This means if we change style props fromStyle.t toarray(Style.t), you could still usearray andarrayOption.
Like said above, this is due to the fact that RN accepts nested arrays, so you can pass in JSstyle={[[{color: "blue"}], [[{"backgroundColor": "red"}]]]} and it will work.

Exactly. Otherwise we would have already run into trouble seeing how helper functions allow recastingarray(Style.t) intoStyle.t.

I like this change, but I further propose definingStyle.style to returnarray<t> instead oft as below. Then, minimal refactoring would needed and we can still continue writingstyle=someStyle. The resulting type definitions would not be less precise in practice either.

style: (  ~resizeMode: resizeMode=?,  ...  ~zIndex: int=?,  unit,) => array<t> = ""

Oh that is actually an interesting idea but maybe that would allow people to write things that will create runtime error likesomeStyle->Array.length ?!

That's a valid concern. Multiple styles would become a worse problem with this too. Joining an actual array and an element would be problematic.

I suppose I haven't thought this through.

Yes this would not be safe

I'm still thinking style should accept an array directly

On my project:

944 usages ofstyle={

• 395 xStyle.array
• 64 xStyle.arrayOption

Like@MoOx said, there is too much dynamic styles on a mobile today: light and dark mode, safe area insets, screen dimensions, ios vs android vs web, …

Yeah I just remember I read something about it, but it say

accessing the returned style objects at runtime is still not recommended as it can prevent static extraction to CSS

so my point about using spread operator is still irrelevant.