-
Notifications
You must be signed in to change notification settings - Fork 26
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
Fix/infinite loop #1234
Fix/infinite loop #1234
Conversation
Deploy Preview for clever-edison-cd22c1 ready! Built with commit dcb8998 https://deploy-preview-1234--clever-edison-cd22c1.netlify.app |
@jaredcwhite I also noticed, |
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.
Hi @dominikx96, good catch on the application language not being saved. (I think there might have been a problem before where we never actually saved it.)
I have some concerns about this PR altering subtle behavior I fixed previously after discovering bugs. Can we basically just include the
conductor.currentStep.save({
language,
})
change, and then for Autofill step just pass a language code directly as the second argument to the constructor?
Regarding the missing listing ID param issue, it looks like the fix in this PR is sort of broken:
https://deploy-preview-1234--clever-edison-cd22c1.netlify.app/applications/start/choose-language
I know in the past we had sort of hack in place which just pulled the first listing out of the result set. Maybe what we should just do instead is redirect to the home page if there's no listing ID param?
@jaredcwhite agree I updated PR to just redirect the user to the Unfortunately, I don't understand the first problem, could you explain it more with code samples? |
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.
OK, I think there was just one specific place where a bug might have crept in again. Otherwise looks good to me—although will need a update for Next v10. Should we get that merged in and then this? Or merge this first?
@@ -37,9 +36,8 @@ export default () => { | |||
setSubmitted(true) | |||
if (previousApplication && useDetails) { | |||
conductor.application = previousApplication | |||
} else { | |||
conductor.application = blankApplication() |
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 had this here so if somebody went back in their browser history and changed to not autofilling the application, it'd be rewritten as a blank application. Otherwise they could never undo their choice.
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.
@jaredcwhite , how close do you think we are to being able to merge the Next branch? If you're thinking next week, then can we get this in first? We're in a tough spot of not wanting to delay the Next updates any longer, but we also don't want to stack up a lot of dependencies.
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.
@seanmalbert Oh I want to get Next v10 ready to merge today, so I think this could follow suit.
@jaredcwhite I realized we can just create a new application object in the autofill step, even if autofill is available - the first step is choose-language, so it works as expected in both situations. Could you check it again? :) |
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.
@dominikx96 Approach looks good to me! 👍
sites/public/lib/appAutofill.ts
Outdated
} from "@bloom-housing/backend-core/types" | ||
import { blankApplication } from "@bloom-housing/ui-components" | ||
|
||
class AutofillCleaner { | ||
application: Application = null | ||
|
||
// provide context value to override current application language choosen by user on the first step | ||
// eslint-disable-next-line @typescript-eslint/no-explicit-any |
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 don't see anything untyped here…do we still need the disable comment?
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.
nice catch! Removing it...
* Prevent infinity loop when listingId is not defined * Override language from the context * Updated test * Redirect to the homepage when there is no listingId * Updated cypress test * Updated autofill to do not override selected language * Cleanup Co-authored-by: dominikx96 <dominik@airnauts.com>
This reverts commit 5076466.
This reverts commit 5076466.
Issue
It's not covered by any issue.
Addresses # (issue)
Description
This PR solves 2 problems:
A language from the
choose-language
step is not saved by a conductor. I also refactored autofill to do not reset context (language is selecting in the first step and autofill is a secondary step - so we need to know what language the user selected)url: http://localhost:3000/applications/start/choose-language without
listingId
parameter occurs infinity loop with GET /listings call to the API.Type of change
How Can This Be Tested/Reviewed?
Checklist: