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

[#8895] Refactor search profile, update alerts and add delete modal #6059

Merged
merged 1 commit into from
Feb 12, 2025

Conversation

sevfurneaux
Copy link
Collaborator

@sevfurneaux sevfurneaux commented Feb 10, 2025

Describe your changes
This PR refactors the search profile, to have a similar pattern of updating the alerts as the Kiezradars component where most of the state is in the parent.

It also updates the search profile alert text and adds the delete modal when deleting search profiles.

Tasks

  • PR name contains story or task reference
  • Steps to recreate and test the changes
  • Documentation (docs and inline)
  • Tests (including n+1 and django_assert_num_queries where applicable)
  • Changelog

@sevfurneaux sevfurneaux self-assigned this Feb 10, 2025
@sevfurneaux sevfurneaux force-pushed the sf-2025-refactor-search-profile-and-update-alerts branch from 31b6202 to b6e14f2 Compare February 10, 2025 11:11
@sevfurneaux sevfurneaux force-pushed the sf-2025-refactor-search-profile-and-update-alerts branch from b6e14f2 to dca7159 Compare February 11, 2025 16:36
return () => document.removeEventListener('keydown', handleKeyDown)
}, [])

useEffect(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

i'd add a null check before calling showModal()

useEffect(() => {
  if (dialogRef.current) {
    dialogRef.current.showModal()
  }
}, [])

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks! Have added 👍

onClose()
}

useEffect(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

we could probably save some performance and drop this useEffect, and add onKeyDown as dialog attribute/prop. see comment below

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nice, that's now removed.

}, [])

return (
<dialog className="kiezradar__modal" ref={dialogRef} aria-modal="true">
Copy link
Contributor

Choose a reason for hiding this comment

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

    <dialog 
      className="kiezradar__modal" 
      ref={dialogRef} 
      aria-modal="true" //can't remember whether we still need this
      aria-labelledby="modal-title"
      onKeyDown={(event) => {
        if (event.key === 'Escape') closeModal()
      }}
    >

Copy link
Contributor

@hom3mad3 hom3mad3 Feb 12, 2025

Choose a reason for hiding this comment

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

also, since we have a title we might add a aria-labelledby="modal-title" and the id="modal-title" to the h3 (adds more context than aria-modal alone)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Added that 👍

const [isEditing, setIsEditing] = useState(false)
const [loading, setLoading] = useState(false)
const [error, setError] = useState(null)
const [profile, setProfile] = useState(profile_)
const [deleteModal, setDeleteModal] = useState(null)

const handleDelete = async () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

what about const handleDelete = useCallback(async () => { ... and handleSubmit? to prevent unnecessary re-renders

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh cool, yes! Both using useCallback now.

profile.project_types,
profile.status.map((status) => ({ name: statusNames[status.name] })),
profile.organisations
searchProfile.districts,
Copy link
Contributor

@hom3mad3 hom3mad3 Feb 12, 2025

Choose a reason for hiding this comment

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

what about destructuring to avoid redundancy ? const { id, name, query_text, districts, topics, project_types, status, organisations, plans_only, notification } = searchProfile;

Copy link
Collaborator Author

@sevfurneaux sevfurneaux Feb 12, 2025

Choose a reason for hiding this comment

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

Tried this, but the linter complains:

  const {
    query_text,
    districts,
    topics,
    project_types,
    status,
    organisations,
    plans_only
  } = searchProfile
  87:5  error  Identifier 'query_text' is not in camel case     camelcase
  90:5  error  Identifier 'project_types' is not in camel case  camelcase
  93:5  error  Identifier 'plans_only' is not in camel case     camelcase
  99:5  error  Identifier 'project_types' is not in camel case  camelcase
 106:6  error  Identifier 'query_text' is not in camel case     camelcase
 108:6  error  Identifier 'plans_only' is not in camel case     camelcase

Let's keep as is for now (and not alias to camelCase, as that is misleading what named properties are actually returned from a search profile).

Side note: I am always battling with this linter before pushing 🙈, mainly around formatting. Maybe in the future, Liquid can change to Prettier formatting, which formats on save in most editors.

</div>
{error && <Alert type="danger" title={errorText} message={error} />}
{isEditing && (
<form className="form--base panel--heavy search-profile__form" onSubmit={handleSubmit}>
Copy link
Contributor

Choose a reason for hiding this comment

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

what do you think of adding <fieldset disabled={loading}> below <form> to prevent submitting multiple times?

onKeyDown={(e) => {
if (e.key === 'Enter') {
e.preventDefault()
e.target.form.requestSubmit()
Copy link
Contributor

Choose a reason for hiding this comment

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

we probably should avoid directly handling the DOM here 🤔 💭

Copy link
Contributor

Choose a reason for hiding this comment

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

sorry a string of meetings interrupted my review 🫠 i think i was going to suggest useRef here..

Copy link
Collaborator Author

@sevfurneaux sevfurneaux Feb 12, 2025

Choose a reason for hiding this comment

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

So it turns out by adding type="button to <button className="link" onClick={() => setIsEditing(false)}> means we no longer need onKeyDown as the browser now natively handles it 🎉

Unsure why doing this fixed it, as it is not the submit button, but prior to this, if we didn't have onKeyDown, Chrome was complaining:

"Form submission canceled because the form is not connected"

@sevfurneaux sevfurneaux force-pushed the sf-2025-refactor-search-profile-and-update-alerts branch from dca7159 to 8d96330 Compare February 12, 2025 10:23
@hom3mad3 hom3mad3 self-requested a review February 12, 2025 10:48
Copy link
Contributor

@hom3mad3 hom3mad3 left a comment

Choose a reason for hiding this comment

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

Thanks ✨

@hom3mad3 hom3mad3 merged commit 3bf140a into dev Feb 12, 2025
2 checks passed
@hom3mad3 hom3mad3 deleted the sf-2025-refactor-search-profile-and-update-alerts branch February 12, 2025 10:49
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