Add support for acceptFirstMouse on window

[Vlemert]

Hey man!

Stumbled upon this project yesterday and I think this is a great idea! Figured I couldn't come empty handed, so here's my first attempt at a contribution. I immediately ran into some interesting stuff because acceptFirstMouse can only be passed as an option in the constructor of Window, which made me think that it only supports being 'uncontrolled'... I think...

Had some trouble testing this as well, so that's still missing. I didn't want to spend a lot of time on that before checking whether this prop is a good idea in the first place. Maybe you were planning on passing the initial options in a different way?

Anyway, love the idea, I'm definitely going to dive into how you got this to work.

[mhink]

Thanks for the PR!

I didn't want to spend a lot of time on that before checking whether this prop is a good idea in the first place. Maybe you were planning on passing the initial options in a different way?

There's not really any other way to pass them in, truth be told, so I think this makes sense. Considering that there's no "controlled" analogue, I would just name the prop acceptFirstMouse and call it a day.

That said, could you add a case for this under WindowElement.commitUpdate which emits a warning if the user changed this prop? I'd like them to know that <window acceptFirstMouse /> is how it's meant to be used.

As far as testing: I totally feel you. I'll tell you what- if you can add a file under the examples/ directory, I'll figure out the "proper" testing (don't feel bad, I still need to add tests for position and size, haha)

[Vlemert]

No problem, happy to help!

So I added an example, removed 'default', and put in probably the lamest warning ever. Totally wasn't sure about how you were planning to do that stuff so I thought I'd just throw it in and we could discuss it. Maybe it's a good idea to put those checks behind a gate so it doesn't run in production, but it seems a mechanism like that is not in there yet.

About the testing, I think I have found out why I had trouble with that, and might have some ideas on how to make it easier. If you're interested I could make a separate issue to share my ideas.

[Vlemert]

Did some more digging in the react codebase and added a stacktrace to the warning message. Went for checking process.env.NODE_ENV before logging, just to be sure.

I created an issue for the stuff I ran into when trying to test this.

[mhink]

Dude, you're a champion. Out of curiosity, what does getFiberStackAddendum do?

[Vlemert]

I found it being used here (and in the files next to that one).

It returns a sort of stack trace of where we are for the current render. If I trigger the warning in the ionize-example-app you'll get this:

I'm not really sure it's perfect like this, but I figured it's better than nothing. I'm still planning on debugging react to see how they use this and what it does over there.