Closed rijk closed 3 years ago
Hi Rijk,
Again, good question!
It's true that defining possibleAnchors
has no effect on the anchor priority.
There is, however, some logic / rationale to which determines the anchor priority dynamically. This function looks at anchor
(the 'preferred' anchor), preferX
, preferY
and possibleAnchors
, and outputs a list of anchors sorted by priority. It than tries to find the first one that 'fits'.
This prioritising is currently implicit, which I think will work for many use-cases (together with preferX/Y
). However, there may be use-cases where you want to prioritise the anchors explicitly.
How would you define such behavior? Right now, possibleAnchors
just sets the available anchors. I don't think that this prop should do 2 things. Maybe an extra prop: anchorPriority
? Or maybe a flag respectAnchorPriority
that 'respects' / overrides the priority based on possibleAnchors
? 😅
What do you think?
If you ask me, this is not important enough to add another property for. I thought it could 'just work' like this, and that would be pretty nice. In this case I wanted BOTTOM_LEFT
/BOTTOM_RIGHT
to be used only as a last resort. It seems preferX
/preferY
cannot really help here.
But yeah, it is not super important, and if there's other considerations here I understand.
I do think your wish is legitimate, but as a consequence it add more complexity. Will keep this open for now and see if others are running into the same issue as well...
I'll close this as it's not that important.
Given the following config:
I would expect this menu to be placed BOTTOM_CENTER:
And this one to be LEFT_CENTER:
Right now, it seems to pick somewhat randomly from the available options. Could this behaviour be changed so it picks the first available option?