Skip to content

Feat: Allow to define the default width/height #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

SBoudrias
Copy link
Contributor

For use within SSR context, it's quite useful to be able to define a default size.

Let me know if this change makes sense for you.

@ZeeCoder
Copy link
Owner

ZeeCoder commented May 20, 2019

Yeah, makes sense. 👍
Can you add it to the changelog and package.json as 3.2.0?

@ZeeCoder
Copy link
Owner

Actually, one more thing: could you try adding a test for it?
If not I can do it as well, but as I'm preparing for my wedding I'm unlikely to have time until mid-June for sure.

@SBoudrias
Copy link
Contributor Author

Hey, I was going to add a test initially, but the current test structure is hard to extend. So I didn't do it.

@ZeeCoder
Copy link
Owner

ZeeCoder commented May 21, 2019 via email

@SBoudrias
Copy link
Contributor Author

I've updated the CHANGELOG and updated the version.

Hopefully we can move forward without the tests as it's not really bringing a lot of values in this specific case.

@@ -1,10 +1,10 @@
import { useEffect, useState, useRef } from "react";
import ResizeObserver from "resize-observer-polyfill";

export default function() {
export default function(defaultWidth = 1, defaultHeight = 1) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest defaulting the default (😆) to 0 so that we can use !!width to test if we've got a width.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be that width / height is actually zero though.
Could return nulls, but I'm not sure it's worth the effort, and it's a breaking change as well.

Do you have a good use-case you'd need this for? @FokkeZB

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes... then only null would work. I don't have a direct need for it right now, but I do think it would make sense to tell the default from an actual value.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to create a separate issue when you have a use-case for it and then we can discuss it. 👍

@ZeeCoder
Copy link
Owner

I've moved things to #10 , which includes tests as well.
@SBoudrias can you check if the changes make sense to you?

Also, could you advise on how to update the TS types?

@ZeeCoder
Copy link
Owner

I think I'll just remove types and do a major release.

@ZeeCoder ZeeCoder closed this Jul 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants