v1.10 and v2 umbrella

[edorivai]

Update (March 17th, 2019)

As described in detail in #123, I'm seriously considering publishing the current changes under a minor version bump: 1.10. The bulk of the preparations for this have already been done in #123.

The next step would be to implement a v2 which uses hooks for the core functionality. I expect a hooks implementation could simplify some of the internals, and would simultaneously allow us to ship a hook as part of the API.

2.0 1.10

• change query prop to queries (Change query to queries #72)
• two-pass render + migrate to componentDidMount (solves Two-pass render on the client #81, Is this SSR ready out of the box? #91, React strict mode #109, PR: Implement two-pass render (closes #81) #96)
• run tests in <Strict> mode (Wrap all tests in <Strictmode> #115)
• merge [WIP] Backward compatibility for the query prop #123
• polish the docs (Start rewriting docs towards queries #119)
• publish a prerelease, and have some people test it out in their production apps

2.1 2.0 (now available as react-media@next)

• implement a hooks API, exposed as react-media/hooks
• reimplement the core functionality using hooks, expose a useMedia hook
• implement a <Media> component, which is compatible with v1.10, but uses said hook internally

I propose exposing Media as the default export and exporting the hook as a named export:

import Media, { useMedia } from 'react-media';

This would allow people to seamlessly upgrade to v2, without having to change existing code. There's also not really any use in splitting things up, since the Media component will be very small (just a wrapper around the hook), and it will use the hook under the hood. So I don't expect us splitting up the files will result in significant bundle size savings.

[tstirrat15]

Want help with any of this?

[edorivai]

@tstirrat15 Feel free to take a stab at any of the last three - Strict mode tests, docs, hooks. I'm a bit short on time, but let me know if you want to start on one, and I'll write up some thoughts I have on that particular item.

[tstirrat15]

Strict mode tests sounds the most immediately tractable. Is that pretty straightforward?

[edorivai]

Yes it should be. The idea would be to wrap all tests in <React.StrictMode>. @mjackson mentioned they're already doing this in react-router. Instead of calling ReactDOM.render directly, they pass their components under test to a renderStrict function they defined, which wraps it in StrictMode.

I don't see any actual assertions around Strict mode, but I guess it would be easily verifiable in the Travis runs as soon as something is violating strict mode.

Does that all make sense?

[tstirrat15]

Yep.

What I've seen in using it in our own project is that it throws warnings at runtime. Is Travis configured to treat warnings as failures? Otherwise it'd probably entail manual review of the test output.

[edorivai]

Yeah I think manual review is fine. I usually run the tests before publishing, but more importantly, when users start complaining that something is not compliant with strict mode, we would be able to verify it quickly by running the tests.

[tstirrat15]

Do you want/need any help with the docs? Did you have an idea for a direction on that?

[edorivai]

I already started on a cleanup of the docs on master. The general idea would be to merge master into next, and then update the breaking API change (query became queries). Though I have an outstanding conversation with @mjackson about whether we might want to keep the query prop in a backwards-compatible way, and just add the queries prop on top.

But I guess you could already perform the merge, and write up some docs on queries. See #72 for details.

Thanks again for the help man!

[tstirrat15]

I'll write a doc block for queries as a separate PR, which we can then merge into next or master as needed. We can remove query and/or add clarification about how they'd work together as a final step.

[South-Paw]

Would it possible to get an RC or alpha build released on npm for the next branch?

I'd really like to see if the 2 pass renderer solves some issues I'm seeing in a project.

Thanks

[edorivai]

@South-Paw Yeah, that would be possible. Only gotcha is that the next branch has a big breaking change, we replaced the query prop for queries. See #119 and #69 for details.

Would it still be useful for you to test out the next branch, given this breaking change?

[South-Paw]

Yeap I think it'd be fine to test it out even with those changes.

It won't be to hard to go through and migrate query to queries - from what I can see I can still put a string into queries and the render pattern remains as {matches => matches ? <div>a</div> : <div>b</div> } right?