feat: implement registration happy path #6
Conversation
| 'no-param-reassign': ['error', { | ||
| props: true, | ||
| ignorePropertyModificationsFor: [ | ||
| 'state', | ||
| ], | ||
| }], |
There was a problem hiding this comment.
Since RTK provides the facility to directly mutate the state object in slice, the ESLint gives error ESLint: Assignment to property of function parameter 'state'.(no-param-reassign). To suppress that error, we are ignoring assignment to state variable.
src/authn-component/index.jsx
Outdated
| const AuthnComponent = ({ open, setOpen }) => ( | ||
| <AppProvider store={configureStore()}> | ||
| <BaseContainer open={open} setOpen={setOpen}> | ||
| <LoginForm /> | ||
| </BaseContainer> | ||
| <BaseContainer open={open} setOpen={setOpen} footerText={messages.footerText}> | ||
| <RegisterForm /> | ||
| </BaseContainer> | ||
| </AppProvider> | ||
| ); |
There was a problem hiding this comment.
Reason for this change:
useIntl() can only be used if the component is wrapped by AppProvider.
Since AuthnComponent has to be provided with store, we wrapped the content of AuthnComponent with AppProvider. And as AppProvider is now wrapped inside AuthnComponent, we could not use useIntl() here. outside of it.
syedsajjadkazmii
force-pushed
the
sajjad/VAN-1885-api-fetching
branch
from
ee56122 to
b098088
Compare
syedsajjadkazmii
force-pushed
the
sajjad/VAN-1885-api-fetching
branch
from
b098088 to
6609703
Compare
| "redux-logger": "3.0.6", | ||
| "redux-mock-store": "1.5.4", | ||
| "redux-saga": "1.3.0", | ||
| "redux-thunk": "2.4.2", |
There was a problem hiding this comment.
Why do we need redux-thunk?
| const loggerMiddleware = createLogger({ | ||
| collapsed: true, | ||
| }); | ||
| return composeWithDevTools(applyMiddleware(thunkMiddleware, sagaMiddleware, loggerMiddleware)); |
There was a problem hiding this comment.
Why are we using thunkMiddleware? just for devtools and if yes do we need to configure devtools?
There was a problem hiding this comment.
No, i dont have a solid reason for this. I just copied the existing configurations from frontend-app-authn. We can surely discuss what was the purpose of thunkMiddleware in frontend-app-authn and decide if we want to keep this or not. Currently I am not aware of why it was added in frontend-app-authn
| * @param {object} registrationInformation - The registration information to be sent to the server. | ||
| * @returns {object} An object containing the redirect URL, success status, and authenticated user details. | ||
| */ | ||
| export default async function registerRequest(registrationInformation) { |
There was a problem hiding this comment.
| export default async function registerRequest(registrationInformation) { | |
| export default async function registerRequest(payload) { |
| import EmailField from '../fields/email-field'; | ||
| import MarketingEmailOptOutCheckbox from '../fields/marketing-email-opt-out-field'; | ||
| import NameField from '../fields/name-field'; | ||
| import PasswordField from '../fields/password-field'; |
There was a problem hiding this comment.
Do we need to segregate our code or are we increasing the code complexity by doing it? I mean now we are writing edX specific code and there would not be any use case like where we are making complex configurable forms.
There was a problem hiding this comment.
This is a modular approach. Currently, we have limited functionality of fields but we will be implementing validations and other use-cases as well. So it would make sense to have separate components for fields instead of writing everything in the registration component.
attiyaIshaque
force-pushed
the
attiya/VAN-1815-registration-form
branch
3 times, most recently
from
5c6c003 to
0f6b354
Compare
Description
This PR implements a happy path for user registration in the authn component's register form.
It uses redux-saga and redux toolkit for implementing API fetching and side effects.
JIRA
VAN-1885
How Has This Been Tested?
Locally
Screenshots/sandbox (optional):
Screen.Recording.2024-04-03.at.4.15.05.PM.mov
Merge Checklist