-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Props Settings UI to match Goals Settings #3322
Conversation
6ec8fd5
to
aafc648
Compare
8a97405
to
6fa3508
Compare
BundleMonFiles updated (2)
Unchanged files (5)
Total files change +254B +0.06% Final result: ✅ View report in BundleMon website ➡️ |
6fa3508
to
c1e649b
Compare
Added c1e649b so in case of creatables and suggestions, the "Create ..." option is not focused by default, instead the first suggestion is highlighted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some UI feedback as well:
- The trashcan icons are cut off somehow?
-
Hitting enter should work for the creatable option as well. For me it doesn't.
-
In the add property modal, when the dropdown is open, hitting escape should only close the dropdown. Currently it also hides the modal. To close dropdown and hide modal, one should hit escape twice.
-
The creatable option shows up very inconsistently for me:
https://github.com/plausible/analytics/assets/3731516/37da80e4-c159-4794-a3ac-c64f8266386f -
The modal takes a few hundred ms to open. How about using
async={true}
for the Combobox to make the modal open interaction more snappy?
and
Both on Safari? Can't repro on Firefox/Chrome, trashcans look fine and hitting enter on "Create..." closes the suggestion popup (unless this is not what you expect?). |
As of ce1e2f6 the suggestions load asynchronously. I also addressed your previous remark about async being default everywhere, unless explicitly set to |
96f314b should give much better experience |
Surprisingly, this one is the hardest to do. On it... |
I think what's going on is Firefox intercepts the escape on input[type=text] to blur focus. I can't use x-on.blur event to close the dropdown because the blur is also fired when you click a suggestion with mouse, leading to a race condition where selecting with mouse is impossible then 😰 |
Just tried Safari: Can you reproduce @ukutaht ? 🤔 |
@aerosol The creatable option focus state looks good now 👍 Hitting enter works fine on creatable. Honestly I think it was working the whole time and I was just confused last time I reviewed... Trashcan icons are still cut off on MacOS Safari but not on MacOS Firefox. @zoldar I noticed you also have a Mac, could you help test if you see the same thing on this branch? |
Sorry. Accidentally hit the wrong button ^ |
Don't have time to thoroughly test this right now but maybe something like this would work? b9e0205 |
@ukutaht the problem I'm struggling with is intercepting the escape key while the input is focused,
|
I have access to a mac but can't reproduce still :/ |
This should be done only once in the live view
We require "Create ..." element to be only focused when there are no suggestions available. This causes some issues, depending on the state, the least focusable index might be either 0 ("Create...") or 1. This patch addresses all the quirks with focus.
So that AlpineJS doesn't think it's a focusable option.
d8057bf
to
b22bdec
Compare
I thought it's maybe the tailwind upgrade, rebase against master, issued |
Staging rebased against master on Safari: @ukutaht can you wipe your node_modules and try again perhaps? |
Co-authored-by: Uku Taht <Uku.taht@gmail.com>
7649166
to
306866d
Compare
7649166 works in the end, it was Vimium-C Firefox add-on blocking it... 🤦 |
This reverts commit 4844857.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll need to up my LV game but at least from what I can understand, it LGTM 😄 ✨ left a couple questions but no showstoppers
defp get_flags(_user) do | ||
%{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we foresee using it again in the near future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, for sure
<li :if={@idx == @suggestions_limit} class="text-xs text-gray-500 relative py-2 px-3"> | ||
Max results reached. Refine your search by typing in goal name. | ||
</li> | ||
<div :if={@idx == @suggestions_limit} class="text-xs text-gray-500 relative py-2 px-3"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, why is it div
instead of li
? AFAIK it's still going to be embedded in a list so it's invalid (but parsable) HTML I think 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it's later on easier to distinguish actual suggestions from non-suggestions in JS :D
socket = | ||
socket | ||
|> assign_new(:site, fn -> | ||
Sites.get_for_user!(user_id, domain, [:owner, :admin, :super_admin]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming that under normal circumstances, site_id
and domain
always match, unless somebody starts fiddling with arguments manually, right (additionally, from what I see, @site_id
is not used anytwhere in LV templates for funnels anyway, only goals)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. site_id
and domain
always match. Even if someone it able to inject that (and bypass server-side signed payload) there is nothing to achieve. And good, point I'll remove the site_id
assign btw of #3323
filter_text: "", | ||
all_props: [prop | socket.assigns.all_props], | ||
displayed_props: [prop | socket.assigns.all_props], | ||
site: %{site | allowed_event_props: [prop | site.allowed_event_props]} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That one is super hard for me to read - perhaps it would be better to split it into a temporary assignment of:
allowed_event_props = [prop | site.allowed_event_props]
and only then set it via:
...
site: %{site | allowed_event_props: allowed_event_props}
...
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure! a4b3e00
Changes
This PR makes the Custom Props settings UI similar to the one introduced in #3293
The diff is against #3321 - please review/merge that one first, I'll then change the base branch.There's several semi-related changes done by the way:
funnels
feature flag is completely removed nowTests
Changelog
Documentation
Dark mode