Equalify React Frontend

[bbertucc]

Summary:

@eekbk will modernize the Equalify.app frontend, transitioning from PHP-rendered views to a React application, aiming to enhance the both the developer and user experience, app performance, and future scalability.

Proposed Solution:

@eekbk will develop a SPA (Single-Page Application) using React. This will involve creating reusable React components corresponding to the current PHP views and components, implementing client-side routing, and ensuring seamless state management. The backend will be interacted with through HTTP requests.

Implementation Plan:

1. Set up React Development environment: Use Create React app for ease of development / auto configuration.
2. Component Development: Refactor each PHP view/component into corresponding React components.
3. API Integration: Convert frontend API requests to JavaScript using either the native fetch() API or the Axios library. Ensure that backend endpoints are compatible.
4. State Management: Employ React's state hooks and the Context API for managing state, providing simplicity and reducing complexity.
5. Routing: Use React Router to handle client-side routing, matching the current URL structure as closely as possible to preserve SEO and user bookmarks
6. Authentication and Session Management: Integrate existing Auth0 authentication into the React application, utilizing tokens for session management and securing private routes.
7. Accessibility Compliance: Ensure comprehensive adherence to WCAG 2.1 AA standards throughout the React application development, ensuring an inclusive user experience. Implement this by:

• Extensive use of semantic HTML5 and ARIA attributes.
• Utilization of Bootstrap’s accessible features, optimizing development speed while adhering to high accessibility standards.
• Thorough accessibility testing to identify and rectify any barriers, ensuring universal usability.

8. UI/UX Consistency: Maintain a cohesive interface that aligns with established styles, leveraging existing assets and libraries and updating them as needed to complement React’s architecture.
9. Testing: Incorporate robust testing methodologies:

• Utilize Jest or Vitest for unit and API integration testing.
• Implement end-to-end testing frameworks like Cypress or Playwright.

10. Documentation: Update project README and other documentation to reflect the new technology stack and ensure a smooth transition for devs currently working on project.
11. Deployment / Rollout: A Blue/Green deployment strategy is recommended, deploying the new React frontend alongside the current PHP one. Once the new version is fully tested and ready, switch traffic from the old to the new. This will allow for quick rollbacks and minimal downtime.

Consideration: Using Next.js for the Project

While the current plan favors a standalone React SPA, considering Next.js would offer the following advantages:

• Enhanced SEO and performance via SSR.
• SSG capabilities for optimal load times and hosting flexibility.
• Simplified routing and potential for integrated API routes.

However, potential trade-offs include a steeper learning curve and additional server requirements, possibly complicating the development landscape.

Conclusion:

Maintaining Equalify's developer-friendly ethos, the preference is towards a standalone React application. Yet, openness to adopting Next.js exists, contingent on community consensus and aligned project objectives.

Budget Proposal

This proposal was approved for $1,000 to support the transition of Equalify.app from PHP-rendered views to a React-based frontend, encompassing development, testing, documentation, and deployment.

Additional Notes

• @eekbk will use placeholder functions for events that haven't been built out in our Equalify backend. These placeholders will simulate the expected interactions and can be easily swapped out with the actual API calls once this issue is completed.

[eekbk]

@bbertucc I realized I didn't specify in the proposal, but I was kind of assuming that you would prefer I use JavaScript over TypeScript for the frontend, because more devs are familiar with JavaScript. Is that true? There could be a case made for TypeScript speeding up development in the long-run because errors would be found more quickly, but certainly I think short term JS would be quicker and accessible to more devs.

[bbertucc]

Either one works @eekbk - whatever you are most comfortable with

[eekbk]

@bbertucc

The Case for Dropping Bootstrap

On an earlier thread discussing styling systems, you mentioned that you preferred Bootstrap bc it has already been integrated along with user testing, but would be open for other options as long as they improved the overall accessibility of the app to both users and developers.

I'd like to make the case for adopting Radix UI and Tailwind (utilizing ShadCN for uniformity and speed of development) instead of Bootstrap.

ShadCN is a collection of components created with RadixUI and Tailwind. Unlike Bootstrap and other component libraries, there is no npm package, rather you copy and paste the component into your code.

Radix is a "low-level UI component library with a focus on accessibility, customization and developer experience". It will serve users and devs with more out-of-the-box accessibility features as opposed to Bootstrap.

Tailwind will streamline development and improve code readability for future devs, eliminating Bootstrap's complex overrides and bulky code.

To address the concerns with any learning curves associated with the tech I will include docs and cheat sheets like this one in the README.

Not to mention that Bootstrap contains its own complexity, opinionation (sp?) and learning curve. And future devs may be less and less familiar with it vs Tailwind and Radix. imho

Let me know how this sounds

[bbertucc]

Closing this since we're moving forward on a different repo