Inline props as object

[davesnx]

Fixes #43.

This PR changes the interface for React.Dom.domProps. Before these changes, domProps was a function with ~400 optional labelled arguments, after these changes we treat it as an object.

There are a few reasons for this change, but the most important is bundle size. jsoo compiles the optional arguments into zeros generating per each domProps call near 400 zeros, jsoo treated labeled arguments as positions into arrays. There are a few issues opened about this, I only found this one though: https://github.com/ocsigen/js_of_ocaml/issues/801

Another of the reasons is about correctness, props in React are an object and after those changes, we treat it as an Object as well. Giving the same flexibility as the underneath layer could enable features that aren't possible on reason-react or rescript/react, for example adding missing attributes, allowing destructuring props in bindings, allowing "data"-attributes or type-safety on certain attributes.

Todos

• [x] Basic functionality with attributes
• [x] What should we do with ref and key
• [x] Type-safe attributes
• [x] Type-safe events
• [x] Add suppressContentEditableWarning
• [x] Add dangerouslySetInnerHTML
• [x] Update snapshot tests
• [x] Add a few test cases
• [x] Fix test baseSuite:refs:forwardRef (maybe it's related with my doubt? probably no)
• [x] Analyze better the bundle-size
• [x] Re-visit dangerouslySetInnerHTML type/format.
• [x] Fix locations for unexpected prop
• [x] Understand why there's nonlabelled props there?

Doubts

I have a doubt about the ref prop. Right now the ref is typed with React.Dom.Ref.t option but React.Dom.domRef doesn't seem to return an optional. But I believe the bindings are not the same as reason-react since they use an anonymous type from the useRef.

File "example/src/Code.re", line 14, characters 14-45:
14 |     <code ref={React.Dom.Ref.domRef(codeRef)}> {text |> React.string} </code>
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: This expression has type React.Dom.domRef
       but an expression was expected of type React.Dom.domRef option

Future

As mentioned before, this change allows us a few niceties on the dom attributes API, from the top of my head:

• -We could add more type-safety on many properties:
  • polyvariants (for example ?preload is now string (* "none", "metadata" or "auto" (and "" as a synonym for "auto") *) into 'None | 'Metadata | 'Auto)
  • dates (for example: max (* should be int or Js.Date.t *) into Js.Date
  • regex
  • etc
• We could add warnings/errors about deprecated attributes
• Try to implement "data" attributes (if the propName starts with "data", we render the value without any typecheck.

PS: I have the editor configured to format using ocamlformat, I believe we should run it across all files (I separate the formatting into one commit, in order to not affect the review)

[jchavarri]

This is a quick analysis of bundle size impact of this PR using webpack-bundle-analyzer.

For each case, I ran:

• make build-prod from project root folder
• Then yarn webpack:production from examples folder (previously adding new BundleAnalyzerPlugin() to webpack plugis list.

This branch (https://github.com/reason-in-barcelona/jsoo-react/pull/66/commits/84e7869ba23ec3c7e9be85233cc4da4318a85920):

Master branch (https://github.com/reason-in-barcelona/jsoo-react/commit/1ff26837c94142005a61fea5316df0028529132d):

[jchavarri]

Bringing this in. Thanks again @davesnx !