Shiksha Social Signup
Check-In At Shiksha
Frontend aspects of Social Signup
Author : Abhishek Baliyan
There aren’t many sites that let you perform some action until you get registered with them. To enhance a user’s experience and customise some things to his/her likings, the website ought to get the user registered. So, it is safe to assume that a user’s journey on a website starts with a registration form. You can say that registration forms give the first impression of a website.
Recently at Shiksha, we had the opportunity to write code from scratch in React in order to migrate our entire registration and response codebase from PHP to PWA.
Why migrate to PWA?
- Old jquery form: Since all the teams in Shiksha were already in the process to migrate their codebase to PWA and microservices, it was apt that we also move our registration form to PWA and microservices. As for all the teams, that had migrated code before the registration revamp were using old PHP form with the help of JQuery. Thus, increasing the codebase size as well as increasing the loading time.
- Social sign up integration: As the world is already moving towards one button signup/login (Google and Facebook authentication), we also wanted our users to register on our site through these mediums. This means a lot of modifications in already existing flow. So, it was better to write the whole codebase from scratch using a better framework.
- Slow speed of existing form: The pain point in the existing form was its slow speed and average user-perceived performance. It took almost 0.5 seconds to show the form to the users (depending on their network speed). Hence, to enhance user experience we opted to move our tech stack to PWA.
- Multiple types of forms/platforms: There used to be 8 different types of forms in Shiksha to support different platforms(Mobile Site, Desktop, Android App), Tech stack (PHP, PWA), purposes. One of the targets that we had in our mind while developing the new form was to club all these forms into a single form that can support all the previous functionalities and add new features to it. Now, there is a single point of control. If you wanna change anything in the form or want to add a layer in between, you can do it in a single place and it will reflect all over the sites for every type of form.
Challenges faced!
- Supporting multiple forms/platforms: One of the obstacles that we faced was how can we support all forms and platforms on a single form. This was done by designing our architecture very carefully keeping in mind all the possible forms that were to be supported. We created a wrapper for our main form and changed all the forms and platforms related data to generic data which was fed as input to our form. The platforms that we supported are mobile, desktop and app.
- Opening the same form as layer, inline and as a separate page: In Shiksha, a form can be used as a layer, inline or on a separate page depending on the needs. To achieve this, we wrapped our layer in a component that can be converted into a layer as well as inline using CSS. But in case of opening it as a new page, we took all the query parameters needed and converted them as our requirements and saved them in store using redux which we used as props in our main container.
- Supporting Non-PWA pages: It all was going smoothly. But then came the humongous task to support non-PWA pages with PWA form. This is where the form on a separate page came into action. So what we did was, we opened the form in an iframe with needed parameters. And then propagating the callbacks with customEvent.
- Cross-Domain Handling: There’s a saying “It’s ok to work with iframes but it is hell if working on cross-domain”. Unfortunately in Shiksha, we have multiple domains that are non-PWA tech architecture such as ask.shiksha.com. It became very burdensome to tackle those pages. What we did there was that we propagated our callback from iframe through postMessages and later caught them in the parent window.
- Code Splitting On-demand loading of Components: Since the form was a part of every possible page, it was increasing their load time as it became the part of their bundling files. To handle it, we used ‘loadable’ for code splitting.
Performance Benchmarking:
- Load Time: The average render time of different layers was within 15 ms which was a considerable difference from the previous PHP form which took almost 0.5 seconds to render.
- Less ajax calls: We designed the flow in such a way that we reduced multiple ajax calls from previous forms. Hence, reducing the overall time for users to fill the form.
Round-Up
Even though this was a challenging task to complete within a comparatively shorter frame of time, we had our fair share of fun, learning, facing new challenges and overcoming them. We learnt what a great and powerful tool we have at our disposal (React). Once you learn the basics, it will be all fun developing your site in React.