Thanks for publishing this project, I am using it for inspiration for the registration flow that I am building, however I am finding that in most cases I need to copy in the classes and refactor to make it suite my use cases.
For example, I want the activation page to have the same styling as my React app and call the activation API so I've copied over the RegisterView and modified it to call my own custom method of send_verify_email that constructs the activation link as such:
activate_link = domain + "/account-activation?token={token}&uidb64={uidb64}".format(
**generate_uid_and_token(user, activation_token))
This ends up being a route in React, which can parse the query parameters from the URL and call the ActivateAccountView. I also copied over ActivateAccountView and modified it to return regular json response. The rationale here is that we want the same look and feel of our react site, otherwise if we were building Django rendered registration flow we would probably just opt for django-registration.
In this case, the API and views come close here, but because we support MFA or OTP using django-otp our registration flows are more complex than the current version of this library supports out of box. That being said it is great to have this scaffolding, I just fear that I won't be getting improvements from your future library updates without going through some vendoring processes to port over what is relevant to my application. Is there ways this could be made more generic, possibly with a corresponding react library that provides some drop in components to pair with the views? Just some thoughts for future improvements.
Thanks for publishing this project, I am using it for inspiration for the registration flow that I am building, however I am finding that in most cases I need to copy in the classes and refactor to make it suite my use cases.
For example, I want the activation page to have the same styling as my React app and call the activation API so I've copied over the
RegisterViewand modified it to call my own custom method ofsend_verify_emailthat constructs the activation link as such:This ends up being a route in React, which can parse the query parameters from the URL and call the
ActivateAccountView. I also copied overActivateAccountViewand modified it to return regular json response. The rationale here is that we want the same look and feel of our react site, otherwise if we were building Django rendered registration flow we would probably just opt fordjango-registration.In this case, the API and views come close here, but because we support MFA or OTP using
django-otpour registration flows are more complex than the current version of this library supports out of box. That being said it is great to have this scaffolding, I just fear that I won't be getting improvements from your future library updates without going through some vendoring processes to port over what is relevant to my application. Is there ways this could be made more generic, possibly with a corresponding react library that provides some drop in components to pair with the views? Just some thoughts for future improvements.