Skip to content
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

Select / typeahead combo for foreign key field #222

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

mkschell
Copy link
Contributor

Apologies for discontiguous PR.

Relevant discussion points from previous (#210

zachdaniel:

So, this is very cool, but I do worry that it can only really be used for low cardinality relationships. i.e if you had 100k users, you would need a type-ahead that would do things like fetch data after a few characters were displayed etc.

If we add this and someone misuses it, it might look good in dev but then when running in prod it could cause significant issues.

Would you be open to making it a typeahead? It doesn't have to look beautiful :)

netProphET:

Yeah that concern crossed my mind as well, and a typeahead could be a good solution. Definitely don't want to provide the rope to hang a production site with. However, not sure I love typeahead for the really low cardinality relationships, e.g. say you have 3 Categories to pick from. I'm happy to play around with this till we have something that will scale.

zachdaniel:

I think it would make sense to do one of two things:
fetch some limited number of results, and if there are less than that that come back, we show a select, and if there are more we show a typeahead.
make it configurable from the outset in the source form. Like configuring it from the source.

So I learned a lot doing this, which is great. I may have gone overboard in how I implemented some of this due to my inexperience with some of the idioms. I'm also unsure about the naming choices for the DSL: admin.label_field and admin.relationship_select_max_items. Also I did not implement a minimum # of characters to wait for in the typeahead yet. It doesn't feel too terrible to me to have it start showing results after 1 keystroke (it does use a 300 ms debounce).

Contributor checklist

  • Bug fixes include regression tests
  • Features include unit/acceptance tests

@@ -2,6 +2,7 @@ import Config

config :ash, :validate_domain_resource_inclusion?, false
config :ash, :validate_domain_config_inclusion?, false
config :ash, :custom_expressions, [AshAdmin.Expressions.Position]
Copy link
Contributor

Choose a reason for hiding this comment

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

We won't be able to use a custom expression like this unfortunately, because once this is deployed the config would be the target users config. We'll have to inline it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, gotcha. I'll take another stab at inlining it.

to reduce cognitive friction from having "query" represent what the user is typing mixed around use of Ash.Query
@mkschell
Copy link
Contributor Author

mkschell commented Dec 2, 2024

Quick update on this: work is still in progress. I've been working with Ash Admin's demo app, which surfaces some concepts I'm still absorbing, and has exposed some weaknesses in my implementation here. More soon.

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.

2 participants