We thought it might be okay to expose accessors to a widget's geometry, as stored in the attached property on the widget. However, further conversation on gitter made us realize it was a bad idea. We document the conversation here so it's available for others.
S. Chris Colbert @sccolbert 11:12
@jasongrout as I'm writing this getGeometry function, I'm wondering if it's a good idea.
because abritrary changes could have changed the size of the widget in the interim
I think that's why I omitted it from the beginning: to force the user who needs to cache sizes, to think carefully about what and how they are doing that
Jason Grout @jasongrout 11:13
you mean without the resize events?
S. Chris Colbert @sccolbert 11:13
yes
the resize message is only sent when a call to setGeometry is different than the previous value
Jason Grout @jasongrout 11:13
right
S. Chris Colbert @sccolbert 11:13
all we know at that point is what we are setting the size to, not that the old values are still correct
what would you be using it for in this case?
Jason Grout @jasongrout 11:14
getting the leaflet size
but I'd expect that the geometry information would be a -1 if the size was unknown
Does the geometry reflect the unknown-ness of sizes?
In other words, if I'm in a container that is not absolutely sized, does the geometry reflect that I don't know my size, or does it calculate the size at a given time and cache that?
S. Chris Colbert @sccolbert 11:19
No, it does not calculate anything, ever.
which is why I don't expose a getter
Jason Grout @jasongrout 11:20
So what is the geometry in the case of a non-absolutely positioned layout?
S. Chris Colbert @sccolbert 11:20
when setting the size, we know the size. The only question is whether we should send a resize message when we do that. It's reasonable enough to check if anything is different from the previous call to setGeometry.
You're not supposed to call setGeometry on a non-absolutely positioned widget
it's not designed for that
Jason Grout @jasongrout 11:21
ah, okay, but you will get resize messages on those widgets anyway
S. Chris Colbert @sccolbert 11:21
Yes, and width/height will be -1
Jason Grout @jasongrout 11:21
I had thought the geometry was essentially a cache for the resize messages, but it's not!
S. Chris Colbert @sccolbert 11:21
i.e. the parent sends the child ResizeMessage.UnknownSize
nope, it only caches the previous values in order to check for a change
to determine whether to send a resize message
Jason Grout @jasongrout 11:22
I guess it's the other way around, actually. geometry sends resize messages, but other things send resize messages too, the unknown resize messages.
S. Chris Colbert @sccolbert 11:22
also, see prepareGeometry and resetGeometry for extra docs
Jason Grout @jasongrout 11:22
yes, I read those too.
S. Chris Colbert @sccolbert 11:24
I think I'm not going to add a getGeometry method. And instead encourage users to cache the sizes from the resize message. There's too many "gotchas" otherwise.
Jason Grout @jasongrout 11:24
Okay, key point here being that you might get a resize message for any number of reasons, and if you want to accurately understand your size, you need to keep track of those, computing dynamically when the resize message doesn't give you a size. In fact, if the resize message doesn't give you a size, you better compute it whenever you need it.
yep.
This should be an issue somewhere you can point people to
S. Chris Colbert @sccolbert 11:24
yep
Jason Grout @jasongrout 11:25
you better compute it whenever you need it.
or do your own invalidation, like the map does...
S. Chris Colbert @sccolbert 11:34
yep