CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List

Expertiza

Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and above all having a solid framework in place to facilitate peer reviews and group comments. The main objective of this project is to develop frontend React Components, with a particular focus on the Student Task list page. The goal is to create a fully functional user interface for these components using React.js and TypeScript.

Introduction

The main objective of this project is to implement the front end for the Student Task list page within Expertiza.

Problem Statement

The Expertiza platform currently lacks an updated and easy-to-use interface for students to view and manage their assignments. Our project's goal is to build a new Student Task List page using React.js, providing a user-friendly, responsive, and accessible experience. We will create a page that not only looks good but also works smoothly across different devices, making it easier for students to see what tasks they have, complete them on time, and keep track of their academic progress.

Design Patterns and Principles

Module Design Pattern:

We use the Module Design Pattern extensively, structuring our application into cohesive, interchangeable components like Table and StudentTasksBox. This pattern allows for a clean separation of concerns and enhances code readability and maintenance.

Lazy Loading & Suspense Pattern:

To improve our application’s performance and user experience, we employ Lazy Loading coupled with the Suspense Pattern. By deferring the loading of components until they are required, we minimize the initial load time and provide a placeholder loading state, ensuring a smooth and responsive interaction for the users.

Memoization Pattern:

Through useMemo, we embrace the Memoization Pattern to cache expensive function calls, avoiding unnecessary recalculations. This is especially beneficial for our dropdown options and table data which depend on the dataset fetched, ensuring that we optimize rendering performance.

Singleton Hook Pattern:

While implicit, our use of React's useState follows the Singleton Hook Pattern. It manages the state within a single instance of a component, preventing the duplication of state logic and preserving the component’s state across re-renders.

Facade Pattern:

The commented useAPI hook represents the Facade Pattern, providing a simplified interface to the more complex logic of API calls. It abstracts the complexities of HTTP requests and state management related to fetching data, making the API interactions more straightforward for the rest of the application.

Observer Pattern with Hooks:

By leveraging useState and useEffect, we implement an Observer Pattern variant that allows our components to efficiently manage and respond to state changes. This hooks-based pattern provides a declarative way to synchronize the component with data and lifecycle events.

Container-Presenter Pattern:

While not explicitly stated, our component structure hints at a Container-Presenter Pattern, with the possibility of segregating logic-heavy containers from UI-focused presentational components. This further aligns with the React best practice of separation of concerns.

Functional Programming Principles:

We adhere to the principles of functional programming by avoiding class-based components and side-effects where possible. Our use of pure functions, hooks, and immutable state within functional components promotes a more predictable and easier-to-test codebase.

DRY Principle:

Consistent with the DRY (Don't Repeat Yourself) Principle, we aim to minimize repetition by reusing components and logic through hooks and utility functions. This not only reduces code bloat but also simplifies updates and maintenance.

Provider Pattern (Potential):

Looking ahead, the implementation may benefit from the Provider Pattern by using React's Context API. This would allow us to pass down the application state and helper functions through the component tree without prop drilling, streamlining the process of sharing stateful logic across components.

Future Considerations

HOC Pattern (Potential):

In future developments, the Higher-Order Component (HOC) Pattern could be leveraged to enhance components with additional capabilities, such as routing or data fetching, without altering their inherent functionality.

Mediator Pattern (Potential):

As the application scales and the complexity of interactions between components increases, the Mediator Pattern could serve as a centralized controller to manage the workflow and logic, facilitating communication between components in a decoupled manner.

Important Links

• GitHub repo [1]
• Pull Request

Team

Mentor

• Chetana Chunduru

Members

• Prathyusha Kodali <pkodali@ncsu.edu>
• Soubhagya Akkena <sakkena@ncsu.edu>
• Sri Lakshmi Kotha <skotha2@ncsu.edu>