feat: add instance and renderer back to RenderResults

[wKovacs64]

Closes #32.

Summary

The instance and renderer fields are documented in the README but were removed from RenderResult in e6ac5ad. I think they add value and (at least renderer) should still be included. This PR re-introduces them to the object returned from render.

Alternatives:

• only include renderer (as instance is just renderer.root anyway)
• leave them out of RenderResult and remove them from the README

Test plan

N/A

[thymikee]

Od rather remove it from the Readme, as that was the intention, just forgot to update it. What's your use case for exposing the renderer?

[wKovacs64]

Debugging, primarily. react-testing-library's debug function is what I wanted but react-native-testing-library's debug is shallow so it was not helpful in my case. renderer.toJSON was my best bet at the time.

[thymikee]

We could add this as an API, how about something like:

degug(<Component />, {deep: true})

?

or returning toJSON from render, if you ever want to snapshot whole component, which actually may make sense for some smaller ones.

I'm also good with adding both.

[wKovacs64]

debug(<Component />, { deep: true }) would be great! I could also see returning toJSON to be useful if you want to keep renderer hidden.

[thymikee]

Yea, we explicitly don't want users to access .getInstance() method. Would you be so kind and update this PR with what we've come up here? 🙂

[wKovacs64]

Thanks, sorry I wasn't able to get to the revamp - you beat me to it! 🙂

[thymikee]

No worries, thanks for you contribution, much appreciated!

[wKovacs64]

Are you still thinking of adding deep debug? I guess that's essentially just a prettified version of toJSON?

[thymikee]

I think we can make it a thing, the API however would rather be debug(<Component />, '', {deep: true}) as we allow second parameter to be a string message.

On the other hand we could check the type of second parameter so you could either use:

debug(<Component />, 'message'); // shorthand, current API
debug(<Component />, {deep: true, message: 'message'}); // debug with more options

wdyt? cc @Esemesek

[Esemesek]

I don't like those configurations. Methods like debug should be short for convenience. We often use those to get a quick feedback, adding configuration as a second parameter will complicate things and will encourage us to add more configurable fields in the future. We could make it happen, but with slight API change:

debug(<Component />, 'message'); // defaults to shallow
debug.shallow(<Component />, 'message'); // same as above
debug.deep(<Component />, 'message'); // deep debug

Additionally, we won't break existing API.
wdyt?

[thymikee]

um, like it!

[Esemesek]

Just like console.log, console.warn etc C:

[wKovacs64]

That looks great.

[thymikee]

we should also use highlight option from pretty-format for nice colors in debug 😉

[thymikee]

@wKovacs64 would you like to build it?

[wKovacs64]

I don't know jack about Flow, so it'd probably be somewhat of a train wreck. 😉