Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-22T22:46:13Z

Dawhite4: /* Testing */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We considered the DRY principle throughout development, ensuring we developed simple, fine-grained, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
For this project we have completed the list and view functions in the student task controller. We used RSwag and Rspec to implement the controller test cases, and postman and swaggerUI to visualize endpoints.

==== Postman ====

In early stages of development, the team used Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function were checked with Postman to verify their parameters, headers, and response values. A Postman collection was first created to enable us to quickly and simply test code changes without manually navigating through the UI each time. The collection contains a request that logs in (and sets authorization variables for the other requests) as well as a list request and a view request:

[[File:Student Task Controller Postman.png| 1200 px]]

On the left, you can see the post request and two get requests under "Student Tasks". In the top-center is the API we are hitting, and in the bottom we see the response from sending the request.

==== Rspec/Rswag ====

Continuing, we developed automated test cases using Rspec/RSwag (https://github.com/rswag/rswag). Functional testing of the controller itself, and the methods we've implemented, are tested with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We tested success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we have tested the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request.</li>
<li>Ensure a user is unable to view tasks without proper authorization, and that they get an error response instead. </li>

</ul>

For example, this is part of the first test for the list controller:
<pre>

path '/api/v1/student_tasks/list' do
get 'student tasks list' do
# Tag for testing purposes.
tags 'StudentTasks'
produces 'application/json'

# Define parameter to send with request.
parameter name: 'Authorization', :in => :header, :type => :string

# Ensure an authorized request gets a 200 response.
response '200', 'authorized request has success response' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

run_test!
end

</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

The test first scopes a path and defines a get request we can implement several tests for. First, it defines a parameter with key 'Authorization' and gives a bearer token stored in an instance variable (computed in the before(:each) block of the spec) using the let syntax. Then, calling ''run_test!'' validates that the response code is correct. In a later test, we also assert statements about the contents of the response by using a block with ''run_test!'':

<pre>
# Ensure an authorized test gets the right data for the logged-in user.
response '200', 'authorized request has proper JSON schema' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

# Run test and give expectations about result.
run_test! do |response|
data = JSON.parse(response.body)
expect(data).to be_instance_of(Array)
expect(data.length()).to be 5

# Ensure the objects have the correct type.
data.each do |task|
expect(task['assignment']).to be_instance_of(String)
expect(task['current_stage']).to be_instance_of(String)
expect(task['stage_deadline']).to be_instance_of(String)
expect(task['topic']).to be_instance_of(String)
expect(task['permission_granted']).to be_in([true, false])

# Not true in general case- this is only for the seeded data.
expect(task['assignment']).to eql(task['topic'])
end
end
</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we assert we have the correct response as well as the fact that the response returned an array of length 5. Finally, we assert the types of all returned data and that the topic is equal to assignment (something manually configured for the seeded test data).

The purpose of the view function is to provide the user interface with data for displaying one student task. The following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

==== Swagger UI ====

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T20:06:34Z

Dawhite4: /* Testing */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We considered the DRY principle throughout development, ensuring we developed simple, fine-grained, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
For this project we have completed the list and view functions in the student task controller. We used RSwag and Rspec to implement the controller test cases, and postman and swaggerUI to visualize endpoints.

In early stages of development, the team used Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function were checked with Postman to verify their parameters, headers, and response values. A Postman collection was first created to enable us to quickly and simply test code changes without manually navigating through the UI each time. The collection contains a request that logs in (and sets authorization variables for the other requests) as well as a list request and a view request:

[[File:Student Task Controller Postman.png| 1200 px]]

On the left, you can see the post request and two get requests under "Student Tasks". In the top-center is the API we are hitting, and in the bottom we see the response from sending the request.

Continuing, we developed automated test cases using Rspec/RSwag (https://github.com/rswag/rswag). Functional testing of the controller itself, and the methods we've implemented, are tested with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We tested success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we have tested the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request.</li>
<li>Ensure a user is unable to view tasks without proper authorization, and that they get an error response instead. </li>

</ul>

For example, this is part of the first test for the list controller:
<pre>

path '/api/v1/student_tasks/list' do
get 'student tasks list' do
# Tag for testing purposes.
tags 'StudentTasks'
produces 'application/json'

# Define parameter to send with request.
parameter name: 'Authorization', :in => :header, :type => :string

# Ensure an authorized request gets a 200 response.
response '200', 'authorized request has success response' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

run_test!
end

</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

The test first scopes a path and defines a get request we can implement several tests for. First, it defines a parameter with key 'Authorization' and gives a bearer token stored in an instance variable (computed in the before(:each) block of the spec) using the let syntax. Then, calling ''run_test!'' validates that the response code is correct. In a later test, we also assert statements about the contents of the response by using a block with ''run_test!'':

<pre>
# Ensure an authorized test gets the right data for the logged-in user.
response '200', 'authorized request has proper JSON schema' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

# Run test and give expectations about result.
run_test! do |response|
data = JSON.parse(response.body)
expect(data).to be_instance_of(Array)
expect(data.length()).to be 5

# Ensure the objects have the correct type.
data.each do |task|
expect(task['assignment']).to be_instance_of(String)
expect(task['current_stage']).to be_instance_of(String)
expect(task['stage_deadline']).to be_instance_of(String)
expect(task['topic']).to be_instance_of(String)
expect(task['permission_granted']).to be_in([true, false])

# Not true in general case- this is only for the seeded data.
expect(task['assignment']).to eql(task['topic'])
end
end
</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we assert we have the correct response as well as the fact that the response returned an array of length 5. Finally, we assert the types of all returned data and that the topic is equal to assignment (something manually configured for the seeded test data).

The purpose of the view function is to provide the user interface with data for displaying one student task. The following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T20:04:21Z

Dawhite4: /* Testing */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We considered the DRY principle throughout development, ensuring we developed simple, fine-grained, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
For this project we have completed the list and view functions in the student task controller. We used RSwag and Rspec to implement the controller test cases, and postman and swaggerUI to visualize endpoints.

A Postman collection was first created to enable us to test endpoints quickly and independently without navigating a UI. The collection contains a request that logs in (and sets authorization variables for the other requests) as well as a list request and a view request:

[[File:Student Task Controller Postman.png| 1200 px]]

On the left, you can see the post request and two get requests under "Student Tasks". In the top-center is the API we are hitting, and in the bottom we see the response from sending the request.

Continuing, we developed automated test cases using Rspec/RSwag (https://github.com/rswag/rswag).

The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we have tested the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request.</li>
<li>Ensure a user is unable to view tasks without proper authorization, and that they get an error response instead. </li>

</ul>

For example, this is part of the first test for the list controller:
<pre>

path '/api/v1/student_tasks/list' do
get 'student tasks list' do
# Tag for testing purposes.
tags 'StudentTasks'
produces 'application/json'

# Define parameter to send with request.
parameter name: 'Authorization', :in => :header, :type => :string

# Ensure an authorized request gets a 200 response.
response '200', 'authorized request has success response' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

run_test!
end

</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

The test first scopes a path and defines a get request we can implement several tests for. First, it defines a parameter with key 'Authorization' and gives a bearer token stored in an instance variable (computed in the before(:each) block of the spec) using the let syntax. Then, calling ''run_test!'' validates that the response code is correct. In a later test, we also assert statements about the contents of the response by using a block with ''run_test!'':

<pre>
# Ensure an authorized test gets the right data for the logged-in user.
response '200', 'authorized request has proper JSON schema' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

# Run test and give expectations about result.
run_test! do |response|
data = JSON.parse(response.body)
expect(data).to be_instance_of(Array)
expect(data.length()).to be 5

# Ensure the objects have the correct type.
data.each do |task|
expect(task['assignment']).to be_instance_of(String)
expect(task['current_stage']).to be_instance_of(String)
expect(task['stage_deadline']).to be_instance_of(String)
expect(task['topic']).to be_instance_of(String)
expect(task['permission_granted']).to be_in([true, false])

# Not true in general case- this is only for the seeded data.
expect(task['assignment']).to eql(task['topic'])
end
end
</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we assert we have the correct response as well as the fact that the response returned an array of length 5. Finally, we assert the types of all returned data and that the topic is equal to assignment (something manually configured for the seeded test data).

The purpose of the view function is to provide the user interface with data for displaying one student task. The following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T20:04:12Z

Dawhite4: /* Testing */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We considered the DRY principle throughout development, ensuring we developed simple, fine-grained, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
For this project we have completed the list and view functions in the student task controller. We used RSwag and Rspec to implement the controller test cases, and postman and swaggerUI to visualize endpoints.

A Postman collection was first created to enable us to test endpoints quickly and independently without navigating a UI. The collection contains a request that logs in (and sets authorization variables for the other requests) as well as a list request and a view request:

[[File:Student Task Controller Postman.png| 1200 px]]

On the left, you can see the post request and two get requests under "Student Tasks". In the top-center is the API we are hitting, and in the bottom we see the response from sending the request.

Continuing, we developed automated test cases using Rspec/RSwag (https://github.com/rswag/rswag).

The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we have tested the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request.</li>
<li>Ensure a user is unable to view tasks without proper authorization, and that they get an error response instead. </li>

</ul>

For example, this is part of the first test for the list controller:
<pre>

path '/api/v1/student_tasks/list' do
get 'student tasks list' do
# Tag for testing purposes.
tags 'StudentTasks'
produces 'application/json'

# Define parameter to send with request.
parameter name: 'Authorization', :in => :header, :type => :string

# Ensure an authorized request gets a 200 response.
response '200', 'authorized request has success response' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

run_test!
end

</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

The test first scopes a path and defines a get request we can implement several tests for. First, it defines a parameter with key 'Authorization' and gives a bearer token stored in an instance variable (computed in the before(:each) block of the spec) using the let syntax. Then, calling ''run_test!'' validates that the response code is correct. In a later test, we also assert statements about the contents of the response by using a block with ''run_test!'':

<pre>
# Ensure an authorized test gets the right data for the logged-in user.
response '200', 'authorized request has proper JSON schema' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

# Run test and give expectations about result.
run_test! do |response|
data = JSON.parse(response.body)
expect(data).to be_instance_of(Array)
expect(data.length()).to be 5

# Ensure the objects have the correct type.
data.each do |task|
expect(task['assignment']).to be_instance_of(String)
expect(task['current_stage']).to be_instance_of(String)
expect(task['stage_deadline']).to be_instance_of(String)
expect(task['topic']).to be_instance_of(String)
expect(task['permission_granted']).to be_in([true, false])

# Not true in general case- this is only for the seeded data.
expect(task['assignment']).to eql(task['topic'])
end
end
</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we assert we have the correct response as well as the fact that the response returned an array of length 5. Finally, we assert the types of all returned data and that the topic is equal to assignment (something manually configured for the seeded test data).

The purpose of the view function is to provide the user interface with data for displaying one student task. The following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T20:03:55Z

Dawhite4: /* Testing */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We considered the DRY principle throughout development, ensuring we developed simple, fine-grained, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
For this project we have completed the list and view functions in the student task controller. We used RSwag and Rspec to implement the controller test cases, and postman and swaggerUI to visualize endpoints.

A Postman collection was first created to enable us to test endpoints quickly and independently without navigating a UI. The collection contains a request that logs in (and sets authorization variables for the other requests) as well as a list request and a view request:

[[File:Student Task Controller Postman.png| 1200 px]]

On the left, you can see the post request and two get requests under "Student Tasks". In the top-center is the API we are hitting, and in the bottom we see the response from sending the request.

Continuing, we developed automated test cases using Rspec/RSwag (https://github.com/rswag/rswag).

The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we have tested the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request.</li>
<li>Ensure a user is unable to view tasks without proper authorization, and that they get an error response instead. </li>

</ul>

For example, this is part of the first test for the list controller:
<pre>

path '/api/v1/student_tasks/list' do
get 'student tasks list' do
# Tag for testing purposes.
tags 'StudentTasks'
produces 'application/json'

# Define parameter to send with request.
parameter name: 'Authorization', :in => :header, :type => :string

# Ensure an authorized request gets a 200 response.
response '200', 'authorized request has success response' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

run_test!
end

</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

The test first scopes a path and defines a get request we can implement several tests for. First, it defines a parameter with key 'Authorization' and gives a bearer token stored in an instance variable (computed in the before(:each) block of the spec) using the let syntax. Then, calling ''run_test!'' validates that the response code is correct. In a later test, we also assert statements about the contents of the response by using a block with ''run_test!'':

<pre>
# Ensure an authorized test gets the right data for the logged-in user.
response '200', 'authorized request has proper JSON schema' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

# Run test and give expectations about result.
run_test! do |response|
data = JSON.parse(response.body)
expect(data).to be_instance_of(Array)
expect(data.length()).to be 5

# Ensure the objects have the correct type.
data.each do |task|
expect(task['assignment']).to be_instance_of(String)
expect(task['current_stage']).to be_instance_of(String)
expect(task['stage_deadline']).to be_instance_of(String)
expect(task['topic']).to be_instance_of(String)
expect(task['permission_granted']).to be_in([true, false])

# Not true in general case- this is only for the seeded data.
expect(task['assignment']).to eql(task['topic'])
end
end
</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we assert we have the correct response as well as the fact that the response returned an array of length 5. Finally, we assert the types of all returned data and that the topic is equal to assignment (something manually configured for the seeded test data).

The purpose of the view function is to provide the user interface with data for displaying one student task. The following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T20:02:05Z

Dawhite4: /* Testing */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We considered the DRY principle throughout development, ensuring we developed simple, fine-grained, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
For this project we have completed the list and view functions in the student task controller. We used RSwag and Rspec to implement the controller test cases, and postman and swaggerUI to visualize endpoints.

A Postman collection was first created to enable us to test endpoints quickly and independently without navigating a UI. The collection contains a request that logs in (and sets authorization variables for the other requests) as well as a list request and a view request:

[[File:Student Task Controller Postman.png| 1200 px]]

The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we have tested the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request.</li>
<li>Ensure a user is unable to view tasks without proper authorization, and that they get an error response instead. </li>

</ul>

As mentioned earlier, the tests were implemented using RSwag (https://github.com/rswag/rswag). For example, this is part of the first test for the list controller:
<pre>

path '/api/v1/student_tasks/list' do
get 'student tasks list' do
# Tag for testing purposes.
tags 'StudentTasks'
produces 'application/json'

# Define parameter to send with request.
parameter name: 'Authorization', :in => :header, :type => :string

# Ensure an authorized request gets a 200 response.
response '200', 'authorized request has success response' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

run_test!
end

</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

The test first scopes a path and defines a get request we can implement several tests for. First, it defines a parameter with key 'Authorization' and gives a bearer token stored in an instance variable (computed in the before(:each) block of the spec) using the let syntax. Then, calling ''run_test!'' validates that the response code is correct. In a later test, we also assert statements about the contents of the response by using a block with ''run_test!'':

<pre>
# Ensure an authorized test gets the right data for the logged-in user.
response '200', 'authorized request has proper JSON schema' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

# Run test and give expectations about result.
run_test! do |response|
data = JSON.parse(response.body)
expect(data).to be_instance_of(Array)
expect(data.length()).to be 5

# Ensure the objects have the correct type.
data.each do |task|
expect(task['assignment']).to be_instance_of(String)
expect(task['current_stage']).to be_instance_of(String)
expect(task['stage_deadline']).to be_instance_of(String)
expect(task['topic']).to be_instance_of(String)
expect(task['permission_granted']).to be_in([true, false])

# Not true in general case- this is only for the seeded data.
expect(task['assignment']).to eql(task['topic'])
end
end
</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we assert we have the correct response as well as the fact that the response returned an array of length 5. Finally, we assert the types of all returned data and that the topic is equal to assignment (something manually configured for the seeded test data).

The purpose of the view function is to provide the user interface with data for displaying one student task. The following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

File:Student Task Controller Postman.png

2024-04-21T19:59:24Z

Dawhite4:

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:57:27Z

Dawhite4: /* Testing */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We considered the DRY principle throughout development, ensuring we developed simple, fine-grained, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
For this project we have completed the list and view functions in the student task controller. We used RSwag and Rspec to implement the controller test cases. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we have tested the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request.</li>
<li>Ensure a user is unable to view tasks without proper authorization, and that they get an error response instead. </li>

</ul>

As mentioned earlier, the tests were implemented using RSwag (https://github.com/rswag/rswag). For example, this is part of the first test for the list controller:
<pre>

path '/api/v1/student_tasks/list' do
get 'student tasks list' do
# Tag for testing purposes.
tags 'StudentTasks'
produces 'application/json'

# Define parameter to send with request.
parameter name: 'Authorization', :in => :header, :type => :string

# Ensure an authorized request gets a 200 response.
response '200', 'authorized request has success response' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

run_test!
end

</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

The test first scopes a path and defines a get request we can implement several tests for. First, it defines a parameter with key 'Authorization' and gives a bearer token stored in an instance variable (computed in the before(:each) block of the spec) using the let syntax. Then, calling ''run_test!'' validates that the response code is correct. In a later test, we also assert statements about the contents of the response by using a block with ''run_test!'':

<pre>
# Ensure an authorized test gets the right data for the logged-in user.
response '200', 'authorized request has proper JSON schema' do
# Attach parameter to request.
let(:'Authorization') {"Bearer #{@token}"}

# Run test and give expectations about result.
run_test! do |response|
data = JSON.parse(response.body)
expect(data).to be_instance_of(Array)
expect(data.length()).to be 5

# Ensure the objects have the correct type.
data.each do |task|
expect(task['assignment']).to be_instance_of(String)
expect(task['current_stage']).to be_instance_of(String)
expect(task['stage_deadline']).to be_instance_of(String)
expect(task['topic']).to be_instance_of(String)
expect(task['permission_granted']).to be_in([true, false])

# Not true in general case- this is only for the seeded data.
expect(task['assignment']).to eql(task['topic'])
end
end
</pre>
spec/requests/api/v1/student_tasks_controller_spec.rb
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we assert we have the correct response as well as the fact that the response returned an array of length 5. Finally, we assert the types of all returned data and that the topic is equal to assignment (something manually configured for the seeded test data).

The purpose of the view function is to provide the user interface with data for displaying one student task. The following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:42:49Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We considered the DRY principle throughout development, ensuring we developed simple, fine-grained, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:38:15Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

 Readability 

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:37:53Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

 Single Responsibility Principle (SRP) 

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

 Don't Repeat Yourself (DRY) 

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

 Open-Closed Principle 

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:36:58Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>
 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:36:30Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

 app/controllers/api/v1/student_tasks_controller.rb: 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

 In spec/requests/api/v1/student_tasks_controller_spec.rb: 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:36:06Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

 In app/controllers/api/v1/student_tasks_controller.rb: 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

 In spec/requests/api/v1/student_tasks_controller_spec.rb: 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:35:55Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

 In app/controllers/api/v1/student_tasks_controller.rb: 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

 In spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:35:19Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

 app/controllers/api/v1/student_tasks_controller.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/app/controllers/api/v1/student_tasks_controller.rb)

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>

 spec/requests/api/v1/student_tasks_controller_spec.rb 
(https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb)

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:34:08Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>

https://github.com/ychen-207523/reimplementation-back-end/blob/main/spec/requests/api/v1/student_tasks_controller_spec.rb

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:33:22Z

Dawhite4: /* Principles */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we have attempted to follow several universal design principles. Similarly, we have tried to be conscious of and avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task. For instance, here's our student task controller's list function:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

In this way, the controller correctly fulfills its single responsibility by handling the request and delegating to the model class.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future. A clear example is in our student task controller tests:

<pre>
def login_user
# Give the login details of a DB-seeded user. (see seeds.rb)
login_details = {
user_name: "john",
password: "password123"
}

# Make the request to the login function.
post '/login', params: login_details

# return the token from the response
json_response = JSON.parse(response.body)
json_response['token']
end

describe 'StudentTasks API', type: :request do

# Re-login and get the token after each request.
before(:each) do
@token = login_user
end

...
...

</pre>

Here, we have common functionality (simulating a log-in to test authenticated endpoints) that we need to run before each test. Instead of putting this code at the start of each method, we factor it out into a common method and apply it in the before(:each) block. This allows us to follow the DRY principle and ensure this code works consistently to keep individual test components independent.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:23:13Z

Dawhite4: /* Implementation */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we will follow several universal design principles. Similarly, we will be conscious of and attempt to avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

Here is the implementation of the list endpoint:

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-21T19:22:31Z

Dawhite4: /* Implementation */

__TOC__

== Github repository ==

Front end:
https://github.com/ychen-207523/reimplementation-front-end

Back end:
https://github.com/ychen-207523/reimplementation-back-end

== Expertiza ==
Expertiza is a Moodle-like open source project developed with Ruby on Rails, designed to enhance the educational experience by allowing students, TAs and instructors to interact on assignments and projects. For instructors, Expertiza can help to create new assignments, review and grade the students’ submissions. For students, Expertiza can provide features to form teams, submit assignments, and provide peer evaluations.

== Problem Statement ==
The scope of this project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2429_Reimplement_student_task_list E2429]. In the previous part, we have implemented the student_task table with React and TypeScript. On this project, we are going to work on the student_task_controller.rb and student_task.rb based on the original design of Expertiza and reimplement them.
 
student_task.rb: This file represents the student task model, will be where we define the relationship between student tasks and other entities such as courses, participants and assignments in the system, as well as any custom logic related to student tasks 
student_task_controller.rb: This file is the controller of student task, we will implement features related with authentication and listing, viewing the student tasks.The main functions this project will focus on are list, which is to gather and organize student tasks to facilitate the display of tasks, and view, which is to display detailed information about a specific student task based on the student id.
 
The student task is highly related with other models such as participant and topic, which have not been implemented or finished yet. For the scope of this project, we will establish the foundational elements of the StudentTask to ensure its capability to interface with the frontend effectively. This approach allows us to set up a framework that can support future teams to incorporate the future implementation into student_task.

== Principles ==
In order to ensure our code is maintainable, extensible, and as simple as possible, we will follow several universal design principles. Similarly, we will be conscious of and attempt to avoid design smells that can indicate code is too rigid, fragile, complex, or difficult to understand.

While developing the student task controller and model, the single responsibility principle (SRP) is important to maintain. The SRP states that each class should not have more than one reason to change- in other words, it should do one thing and do it well. The first implication of this principle is that the controller should not contain significant application logic; the controller’s primary responsibility is to handle requests and call the appropriate methods. Therefore, it should delegate to the model class for any complex logic. The principle can also be applied to functions within the model class itself. Ideally, the student task controller will call simple and reusable functions in the model class that each perform one task.

The reusability of components follows another important principle- do not repeat yourself, also known as DRY . Essentially, the same code should not exist in two different places if it does the same thing- instead, the design of components should enable the code to be written once and called multiple times. This reduces the complexity of the application, ensures the code always does the same thing, and makes testing the code simpler and more effective. We will consider the DRY principle throughout development, ensuring we develop simple, granular, and reusable functions for the student task model that can be reused by other components in the future.

The open-closed principle states that classes should be open for extension but closed for modification. Following this principle, the student task controller should interact with the model through method calls encapsulated in the model and not modify any data for the model itself. Additionally, we need to be cognizant of the overall design of the model and controller so they don’t need to change in order to implement new functionality in the future. Again, this will be achieved by keeping the code modular and ensuring the student task model’s methods adhere to principles of encapsulation and single responsibility.

Finally, it’s important to make code as readable as possible. If developers understand code more quickly, the code is more maintainable, extensible, and less likely to cause unforeseen errors. Therefore, we will follow several best practices for code readability:

<ul>

<li> Narrowest Scope: Give a variable the narrowest scope you can. By giving the narrowest scope by default, we constrain variables to the context in which they are needed, reducing the need for developers to reason about too many variables. </li>

<li> Conciseness: Code should be as concise as possible while being simple to understand. </li>

<li> Variable Names: Variable names should be long enough to be descriptive, but not longer than necessary. Variables that are only used once or twice may be a bit longer than variables used throughout the code, since the developer may be much more familiar with these variables. </li>

<li> Consistency: Follow conventions that exist in the present code. Unless there are fundamental differences, a problem should not be solved in different ways by the same code base. By using existing solutions and conventions, we make our code easier to use in the context of the system and help developers understand the implementation. </li>

<li> Commenting: Provide informative comments about the purpose of code. Obvious things that are clarified by concise and readable syntax don’t need to be explained; instead, we will focus on providing developers with context for any sequence of operations that merits explanation. </li>

</ul>

== Implementation ==

Prerequisite: Given that the StudentTask heavily relies on data from the Participant table, we will utilize the existing Participant model, controller, database table, and schema. Once the new Participant model and controller are completed, the future team should integrate these updates to ensure that the StudentTask remains fully functional. 
Another inseparable element of the StudentTask table is the topic; however, implementing the supporting backend for topics is beyond the scope of our current project. Therefore, we will utilize JSON data to mimic the interaction and data structure of topics. This method allows us to simluate the topic without implementing. Also, The future team can integrate the implemented topic part into student task easily without conflict. 
student_task.rb: The first step to approach is to clearly define the model's attributes, relationships, and foundamental functionalities. Based on the previous implementation we understand that the student task is created based on participant. To maintain the consistency, we plan to implement the method for creating StudentTask instances directly from participants. Utilitze the existing participant is to follow the approach of Do not Repeat Yourself (DRY) and Single Responsibility Principle.
<pre>
def initialize(args)
@assignment = args[:assignment]
@current_stage = args[:current_stage]
@participant = args[:participant]
@stage_deadline = args[:stage_deadline]
@topic = args[:topic]
end

def self.from_participant(participant)
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (begin
Time.parse(participant.stage_deadline)
rescue StandardError
Time.now + 1.year
end)
)
end
</pre>
Also, we will add other functions such as ''complete?'', ''not_started?'', and other facilitating methods to enrich the model's interactivity and user feedback capabilities.This approach is to follow Open/Closed Principle that student_task can have more behaviors by adding new functions but existing functions remain the same.
 
student_task_controller.rb: This file contains the endpoints provided by our functionality- the list endpoint and the view endpoint.

Information for the list endpoint is obtained in the old system by querying the participants database (there is no separate student task database). To maintain this for the new system, we created a Student Task model function we can call from the view. In this way, we keep the bulk of application logic in the model class and allow the controller to focus on its single responsibility- routing and transforming requests.

<pre>
def list
@student_tasks = StudentTask.create_tasks_from_user current_user
render json: @student_tasks
end
</pre>

This list function is attached to the /api/v1/student_tasks endpoint using routes.rb. It calls StudentTask's create_tasks_from_user method on the authenticated user (current_user) and returns the result as JSON for the front end.

The old student task controller handled other functionality as well- checking if the user is a new user, handling impersonation, and getting students who have teamed with a user. However, this is a result of using rails for the front end and the back end, and trying to implement something similar would just result in tight coupling between the front and back end (as well as violating the SRP). Instead, this functionality should be appropriately split into different endpoints and modularized to improve the maintainability, flexibility and testability of the code.

 
After we finish the implementation of list, we will move on to ''view''. Here is the current design of view:
<pre>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = @participant.authorization
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
@use_bookmark = @assignment.use_bookmark
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
# To get the current active reviewers of a team assignment.
# Used in the view to disable or enable the link for sending email to reviewers.
@review_mappings = review_mappings(@assignment, @team.id) if @team
end
</pre>
The current design is to provide detailed information about a specific sutdent task based on the participant id, then it gathers different information from the participant along with the pther required information such as topic and time line. Therefore, the student task is highly related with participant.
 
For our project, we intend to keep the same design idea, we will start from implementing ''list'' function to provide a comprehensive and filtered overview of student task based on the role of the current user. This will give us a solid start point. After we finsih implementing ''list'', we will move on to ''view'', focusing on offering detailed information about individual student tasks.
The design principles include the Single Responsibility Principle (SRP), ensuring each component of our application is tasked with a single responsibility, and the Principle of Least Privilege (PoLP), ensuring users access only the data and actions relevant to their role.

== UML ==
[[File:Student task uml.jpeg | 1200 px]]

The user sends request through the UI to student_task_controller.
 
In List function, the controller sends request to student_task model for an instance, the student_task model will gather information from participant based on the participant parameter and send the intance to controller. After assembling these instances with the necessary details, the StudentTask model returns them to the controller, which then renders the appropriate view to display the tasks to the user.
 
In the view function, it gathers the information of a specific StudentTask based on the given participant id. It also retrieves the information of the participant such as ability to submit work, review others, take quizzes, authentication and etc.This process enables a detailed and personalized overview of the student task.

== Testing ==
The minimum scope of the project is to complete the list function in the student task controller. The purpose of the list function is to provide the user interface with data for displaying the student task table. Accordingly, we will test the following cases for the list function:

<ul>

<li>Ensure a user gets all their tasks with correct attributes when they request. (For this case, various users will be tested with different tasks). </li>
<li>Ensure a user is unable to view tasks for another user. </li>
<li>Ensure a user gets tasks without error when some data is missing. </li>

</ul>

Additionally, the team hopes to complete the view function, which displays information about a specific task. If this functionality is finished, the following cases will be tested:

<ul>

<li> Ensure a user is able to view any task retrieved from the table. </li>
<li> Ensure the user gets correct attributes when they request. </li>
<li> Ensure a user may view a task without error when some data is missing. </li>

</ul>

In early stages of development, the team will be using Postman (https://www.postman.com) in order to test API endpoints exposed by the student task controller. Specifically, the endpoints for the list function and the view function will be checked with Postman to verify their parameters, headers, and response values. By using Postman in early stages, the team hopes to quickly and simply test code changes without manually navigating through the UI each time.

After the endpoints have been implemented, they will be compiled and thoroughly tested using Swagger UI (https://swagger.io/tools/swagger-ui/). Swagger UI enables users to test various requests and view their responses in an accessible web interface. The platform will enable us to quickly test endpoints with different parameters and validate the structure of responses with models we can define.

Additionally, we will do functional testing of the controller itself, and the methods we've implemented, with Rspec (https://rspec.info/features/6-0/rspec-rails/controller-specs/). We will test success and error responses with valid and badly-formed requests in order to ensure our components are reliable and secure. Automating tests is important for preserving existing functionality, especially when changes are made.

== Process ==

====Project Board====

We utilize a project board on GitHub in order to track and delegate our tasks that the reimplementation is comprised of.

[https://github.com/users/ychen-207523/projects/10/views/1 project board]

We initialize our tasks on the board and so that they can be tracked and our progress can be followed by each team member, regardless of their level of responsibility in a single task. That way, even if a team member isn't directly responsible for a sub-task, a single source of truth displays to everyone the state of the project at any point in time.

Moreover, our design documentation should allow us to create a roadmap and tasks before designing code, so that the course of action is clear and the tasks can be evenly delegated.

====Code Quality====

By laying out all of the incremental steps we have in order to reimplement the student task controller, we ensure that all boxes are checked in redesigning the software. Moreover, adequate comments throughout the code, and adherence to best practices will ensure our code is readable, robust, and inline with industry standards.

Moreover, sufficient testing and peer reviews should also ensure our code is up to the highest quality.

====Communication====

We communicate on a regular basis using a text group chat. Moreover, we have scheduled formal calls at least once a week to discuss current objectives and progress. Additionally we often jump on a less unscheduled calls to pair program and problem solve.

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-08T20:45:52Z

Dawhite4: /* Testing */

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-08T16:06:33Z

Dawhite4: /* Testing */

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-08T16:04:56Z

Dawhite4: /* Principles */

CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller

2024-04-08T16:03:38Z

Dawhite4:

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T16:06:58Z

Dawhite4: /* Team */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidance =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

===== Style Changes =====

We found that the table utilized by the refactored Expertiza required a few styling changes to match that of the original one. In order to maintain the alternating style of the table, we overrode the style of the header and the bootstrap class with css:

<pre>

.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>th {
background-color: #ffffff;
--bs-table-bg-type: none
}

.student-tasks .table-striped>tbody>tr:nth-of-type(even)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>th {
background-color: #f2f2f2;
--bs-table-bg-type: none;
}
</pre>

Where we use .student-tasks to restrict the change to the student task list, then use selectors to overwrite the color of even and odd rows of the table.

Additionally, we added a headerCellStyle prop to the Table to enable consuming code to specify the color, font color, or any other style of the header when creating a table. This was used in our code to overwrite the header background color and is demonstrated in our Table component "headerCellStyle" prop:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

See the changes section for more specific one-to-one UI comparisons between the refactored version and the old Expertiza.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

Students:

David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:

Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T16:06:48Z

Dawhite4: /* Team */

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T16:06:41Z

Dawhite4: /* Team */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidance =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

===== Style Changes =====

We found that the table utilized by the refactored Expertiza required a few styling changes to match that of the original one. In order to maintain the alternating style of the table, we overrode the style of the header and the bootstrap class with css:

<pre>

.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>th {
background-color: #ffffff;
--bs-table-bg-type: none
}

.student-tasks .table-striped>tbody>tr:nth-of-type(even)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>th {
background-color: #f2f2f2;
--bs-table-bg-type: none;
}
</pre>

Where we use .student-tasks to restrict the change to the student task list, then use selectors to overwrite the color of even and odd rows of the table.

Additionally, we added a headerCellStyle prop to the Table to enable consuming code to specify the color, font color, or any other style of the header when creating a table. This was used in our code to overwrite the header background color and is demonstrated in our Table component "headerCellStyle" prop:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

See the changes section for more specific one-to-one UI comparisons between the refactored version and the old Expertiza.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

Students:
David White (dawhite4@ncsu.edu)

Henry McKinney (hmckinn@ncsu.edu)

Yunfei Chen (ychen267@ncsu.edu)

Mentor:
Kashika Malick (kmalick@ncsu.edu)

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T16:05:17Z

Dawhite4: /* Team */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidance =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

===== Style Changes =====

We found that the table utilized by the refactored Expertiza required a few styling changes to match that of the original one. In order to maintain the alternating style of the table, we overrode the style of the header and the bootstrap class with css:

<pre>

.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>th {
background-color: #ffffff;
--bs-table-bg-type: none
}

.student-tasks .table-striped>tbody>tr:nth-of-type(even)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>th {
background-color: #f2f2f2;
--bs-table-bg-type: none;
}
</pre>

Where we use .student-tasks to restrict the change to the student task list, then use selectors to overwrite the color of even and odd rows of the table.

Additionally, we added a headerCellStyle prop to the Table to enable consuming code to specify the color, font color, or any other style of the header when creating a table. This was used in our code to overwrite the header background color and is demonstrated in our Table component "headerCellStyle" prop:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

See the changes section for more specific one-to-one UI comparisons between the refactored version and the old Expertiza.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

Students:
David White
Henry McKinney
Yunfei Chen

Mentor:
Kashika Malick

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:54:28Z

Dawhite4: /* Style Changes */

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:52:14Z

Dawhite4: /* Style Changes */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidance =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

===== Style Changes =====

We found that the table utilized by the refactored Expertiza required a few styling changes to match that of the original one. In order to maintain the alternating style of the table, we overrode the style of the header and the bootstrap class with css:

<pre>

.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>th {
background-color: #ffffff;
--bs-table-bg-type: none
}

.student-tasks .table-striped>tbody>tr:nth-of-type(even)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>th {
background-color: #f2f2f2;
--bs-table-bg-type: none;
}
</pre>

Where we use .student-tasks to restrict the change to the student task list, then use selectors to overwrite the color of even and odd rows of the table.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

See the changes section for more specific one-to-one UI comparisons between the refactored version and the old Expertiza.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:51:29Z

Dawhite4: /* Style Changes */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidance =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

===== Style Changes =====

We found that the table utilized by the refactored Expertiza required a few styling changes to match that of the original one. In order to maintain the alternating style of the table, we overrode the style of the header and the bootstrap class with css:

 
{
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>th {
background-color: #ffffff;
--bs-table-bg-type: none
}
}


 
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>th {
background-color: #f2f2f2;
--bs-table-bg-type: none;
}


Where we use .student-tasks to restrict the change to the student task list, then use selectors to overwrite the color of even and odd rows of the table.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

See the changes section for more specific one-to-one UI comparisons between the refactored version and the old Expertiza.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:51:05Z

Dawhite4: /* Style Changes */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidance =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

===== Style Changes =====

We found that the table utilized by the refactored Expertiza required a few styling changes to match that of the original one. In order to maintain the alternating style of the table, we overrode the style of the header and the bootstrap class with css:

 
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>th {
background-color: #ffffff;
--bs-table-bg-type: none
}


 
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>th {
background-color: #f2f2f2;
--bs-table-bg-type: none;
}


Where we use .student-tasks to restrict the change to the student task list, then use selectors to overwrite the color of even and odd rows of the table.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

See the changes section for more specific one-to-one UI comparisons between the refactored version and the old Expertiza.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:50:39Z

Dawhite4: /* Code Changes */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidance =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

===== Style Changes =====

We found that the table utilized by the refactored Expertiza required a few styling changes to match that of the original one. In order to maintain the alternating style of the table, we overrode the style of the header and the bootstrap class with css:

 
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(odd)>th {
background-color: #ffffff;
--bs-table-bg-type: none
}

.student-tasks .table-striped>tbody>tr:nth-of-type(even)>td,
.student-tasks .table-striped>tbody>tr:nth-of-type(even)>th {
background-color: #f2f2f2;
--bs-table-bg-type: none;
}


Where we use .student-tasks to restrict the change to the student task list, then use selectors to overwrite the color of even and odd rows of the table.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

See the changes section for more specific one-to-one UI comparisons between the refactored version and the old Expertiza.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:34:37Z

Dawhite4: /* Current View */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

See the changes section for more specific one-to-one UI comparisons between the refactored version and the old Expertiza.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:33:12Z

Dawhite4: /* Current View */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

The updated UI preserves many of the styling elements from the existing Expertiza, including color schemes and formatting, while making the page appear more compact and information-dense as well.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:32:09Z

Dawhite4: /* Current View */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

After making all of the updates and reimplementing the page, the new student task list page looks like this:

[[File:StudentTaskTable_FullUI_Medium.png]]

For reference, this is the old Expertiza:

[[File:StudentTaskTable_OldUI_Large.png]]

As shown above, we have re-implemented all existing functionality and added some improvements, like dropdown filters and a search function.

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:29:18Z

Dawhite4: /* Current View */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

[[File:StudentTaskTable_FullUI_Medium.png]]

[[File:StudentTaskTable_OldUI_Large.png]]

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

File:StudentTaskTable OldUI Large.png

2024-03-24T15:28:48Z

Dawhite4:

File:StudentTaskTable FullUI Medium.png

2024-03-24T15:27:17Z

Dawhite4: Dawhite4 uploaded a new version of File:StudentTaskTable FullUI Medium.png

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:26:14Z

Dawhite4: /* Current View */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

[[File:StudentTaskTable_FullUI_Medium.png]]

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

File:StudentTaskTable FullUI Medium.png

2024-03-24T15:26:06Z

Dawhite4:

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:25:25Z

Dawhite4: /* Current View */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

[[File:StudentTaskTable_FullUI_Medium.jpeg]]

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

File:StudentTaskTable FullUI Medium.jpeg

2024-03-24T15:25:15Z

Dawhite4:

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:24:26Z

Dawhite4: /* Current View */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

[[File:E2429_StudentTaskTable_FullUI.png]]

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:23:55Z

Dawhite4: /* Current View */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

E2429_StudentTaskTable_FullUI.png

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

File:E2429 StudentTaskTable FullUI.png

2024-03-24T15:23:16Z

Dawhite4:

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:18:03Z

Dawhite4: /* Lazy Loading */

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

</pre>
Component Wrapping for StudentTasksBox:

<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==

CSC/ECE 517 Spring 2024 - E2429 Reimplement student task list

2024-03-24T15:14:30Z

Dawhite4:

__TOC__
== Introduction ==
The [http://expertiza.ncsu.edu/ Expertiza] application is a collaborative platform used by students and instructors for managing assignments, peer reviews, and feedback. The current student task list interface
lacks responsiveness, usability, and performance. The objective is to reimplement the frontend of the student task list using React JS and TypeScript. This reimplementation aims to enhance the user experience, improve task management, and optimize performance.

== Project Requirements ==
The project will focus on the following features:
# Dynamic Task Table: Display a table listing student assignments. columns: Assignment name, course, topic, current stage, review grade, badges, stage deadline, and publishing rights.Implement sorting and filtering functionalities for efficient task navigation.
# Responsive Design: Prioritize accessibility and user-friendly layouts.
# Lazy Loading: Optimize performance by loading content only when necessary.Improve page load times for a smoother user experience.

== Dummy Data ==

=====Interfaces=====

The interfaces were designed as a prototype for testing purposes. The future team working on the backend needs to modify it as needed.

The implementation can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/interfaces.ts here]

Duty and StudentsTeamedWith is for the side box.

Revision's purpose is undefined for now, so leave it empty, the future team should delete it if it is proved to be redundant.

IStudentTask is for the main table of student task.

<pre>
export interface Duty {
name: string;
dueDate: string;
}

export interface Revision {

}

export interface StudentsTeamedWith {
[semester: string]: string[];
}

// Interface for matching columns to assignment table columns
export interface IStudentTask {
name: string;
course_name: string;
topic: string;
current_stage: string;
review_grade: {
comment: string;
};
has_badge: boolean;
stage_deadline: Date
publishing_rights: boolean

}

</pre>

=====JSON File=====

JSON File are also created for the purpose of testing, the future team should delete this file if the data can be successfully retrieved from the database.

JSON File can be found [https://github.com/ychen-207523/reimplementation-front-end/blob/main/src/pages/StudentTasks/assignments.json here]

<pre>
{
"assignments": [
{
"name": "Assignment 1",
"course_name": "CSC 517",
"topic": "Ruby",
"current_stage": "in progress",
"review_grade": {
"comment": "3/5"
},
"has_badge": false,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 517",
"topic": "Rails",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": true
},
{
"name": "Assignment 3",
"course_name": "CSC 517",
"topic": "Git",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": true,
"stage_deadline": "3/18",
"publishing_rights": false
},
{
"name": "Assignment 1",
"course_name": "CSC 522",
"topic": "AI",
"current_stage": "in progress",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/25",
"publishing_rights": true
},
{
"name": "Assignment 2",
"course_name": "CSC 522",
"topic": "Random Forest",
"current_stage": "finished",
"review_grade": "N/A",
"has_badge": false,
"stage_deadline": "3/28",
"publishing_rights": true
}
],
"duties": [
{
"name": "CSC517-Assignment 1",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 2",
"dueDate": "2024-03-18"
},
{
"name": "CSC517-Assignment 3",
"dueDate": "2024-03-18"
},
{
"name": "CSC522-Assignment 1",
"dueDate": "2024-03-25"
},
{
"name": "CSC522-Assignment 2",
"dueDate": "2024-03-28"
}
],
"revisions": [

],
"studentsTeamedWith": {
"CSC540, Fall 2023": ["classmate one", "classmate two", "classmate three", "classmate four"],
"CSC515, Spring 2024": ["classmate five", "classmate six", "classmate seven"]
}
}

</pre>

== Changes ==

=== Student Task Page ===

==== Dummy Data ====
The fetching of the data and rendering of the table slightly differs due to the fact that data is being called from a local JSON file as apposed to being fetched via an API.

The UI is contained within the file src/pages/StudentTasks/StudentTasks.tsx

Data is imported from the JSON file in the following as follows:

<pre>
import testData from './assignments.json';
</pre>

<pre>
Therefore the table data is defined as follows:
</pre>

const tableData = useMemo(() => testData.assignments, []);

However when actually importing from the backend the following import will likely be used:

<pre>
// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
import useAPI from "hooks/useAPI";
</pre>

This should be the API call to the backend to retrieve the student tasks from the DB.

<pre>
// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/
</pre>

=== Main Table ===

==== UI changes ====

Previous UI:
 
[[File:Prior UI StudentTasks Table.png]]
 
Current UI:
 
[[File:New UI StudentTasks Table.png]]

Changes 
* Create new student assignments / tasks table utilizing TypeScript to implement main features and functionalities prior version.
* Added a search box at the top for searching any input related to assignments.
* Added a dropdown for every column to filter assignments accordingly.
* Added a page navigation feature under the table.

==== Code Changes ====

===== New TypeScript Student Tasks Table =====

There are three main files associated with the rendering of this table and the Student Tasks UI as a whole:

1) src/pages/StudentTasks/StudentTasks.tsx

Renders the UI and contains the logic for the table.

2) src/pages/StudentTasks/StudentTaskColumns.tsx
Defines the table's columns.

3) src/components/Table/Table.tsx
Defines the base logic for the table implementation.

===== Dropdown Feature & Developer Implications + UI Guidence =====
We edited the class src/components/Table/Table.tsx to have a accommodate three different options for searching the columns: a dropdown, a search box (input) or neither.

in Interface TableProps see:
<pre>

// Table.tsx

interface TableProps {
// other properties...

// new property for search control
columnSearchMode?: 'none' | 'input' | 'dropdown';
dropdownOptions?: Record<string, string[]>; // if 'dropdown', provide options for each column
}
</pre>

We defined the default column search property to be a search box (input) as seen below:

<pre>

// Table.tsx

const Table: React.FC<TableProps> = ({
// other properties...
columnSearchMode = 'input' // default when creating a Table

})

</pre>

As a feature of our implementation and design, the developer has options for choosing which columnSearchMode to implement:

Currently, columnSearchMode is parameterized with the dropdown option as seen in UI of table above.

Therefore when rendering the table in StudentTasks.tsx, columnSearchMode can be parametrized with 3 different options based on the developer's choosing.

<pre>

// StudentTasks.tsx

<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>

</pre>

Parameterizing columnSearchMode with 'none' or 'input' is as simple as entering said parameter name, nothing else is required and the UI should render.

However, for 'dropdown', the dropdownOptions prop needs to be included to pull data for the dropdown.

=== Side Table ===

==== UI changes ====

Previous UI:
 
[[File:Side Box UI Original.png]]
 
Current UI:
 
[[File:Side Box UI Current.png]]

Changes 
* Transfer all the code from Ruby on Rails views to React and TypeScript.
* Delete the line between Course Name and the start of team member list
* Add the line between the end of team member list and Course Name

==== Code changes ====

This task was implemented mainly in two files: StudentTasks.css and StudentTasksBox.tsx

* StudentTasks.css
This file contains the majority of the styles of this box.

* StudentTasksBox.tsx

First, defined interface for the table data and pass these data as parameters

<pre>
interface StudentTasksBoxParameter {
duties: Duty[];
revisions: Revision[];
studentsTeamedWith: StudentsTeamedWith;
}

</pre>

We also need to define a function to calculate days left with the the current time and due time
<pre>
const calculateDaysLeft = (dueDate: string) => {
const today = new Date();
const date = new Date(dueDate);
const differenceInTime = date.getTime() - today.getTime();
const differenceInDays = Math.ceil(differenceInTime / (1000 * 3600 * 24));
return differenceInDays > 0 ? differenceInDays : 0;
};
</pre>

Next, we need to filter out those assignments that have not yet reached their due date.
<pre>
const tasksNotStarted = duties.filter(duty => (calculateDaysLeft(duty.dueDate) > 0))
</pre>

Finally, we can display the data as intended template

Task not yet start
<pre>

   {tasksNotStarted.length}  Tasks not yet started 

 
{tasksNotStarted.map(task => {
const daysLeft = calculateDaysLeft(task.dueDate);
const dayText = daysLeft > 1 ? 'days' : 'day';
return (
<div>
   » {task.name} ({daysLeft} {dayText} left)
</div>
)
})}
</pre>

Student who have teamed with you
<pre>

Students who have teamed with you 

 

{
Object.entries(studentsTeamedWith).map(([semester, students]) => (
<div>
   
{students.length} 
  {semester}
 
{students.map((student => (
<div>
  » {student} 
</div>
)))}
 
</div>
))
}
</pre>

=== Lazy Loading ===

In order to increase website responsiveness and improve overall performance, several optimizations can be made. One optimization implemented involved the use of lazy loading components, delaying sending components to the client until the client page "needs" them.

By default, React applications typically bundle all javascript files so that the user has all necessary files it needs to explore and interact with the whole site. This isn't a problem for small applications, but as the size of the application grows, the user may be sent more and more data at first load, meaning there is a longer initial load time and that the user may waste network bandwidth to get code for pages they will never visit.

Lazy loading solves this issue by allowing developers to delay the loading of components until they are first used. Any components which are loaded lazily are not sent on initial page load, but instead sent only when the browser needs them to render a view. This can result in more network transactions between the client and server, but can greatly reduce the size of these transactions, particularly the first one. Since this is a common problem, React offers a simple API for it, allowing users to mark components as lazy, surround them with a <Suspense> tag and give a fallback component to render until the data has been fetched for the component itself.

https://react.dev/reference/react/lazy

To improve the responsiveness of the site, we decided to use lazy loading for the components of the student task list. The page is primarily made up of a Table component (which renders the student task table) and a StudentTasksBox component, which renders a summary of the student's important information in a box on the left side of the screen. To make these changes, we just had to change how the components were imported and wrap the rendering of the components in the appropriate component (Suspense).

Lazy Loading of the Table and StudentTasksBox:

<pre>

// Load components lazily.
const Table = lazy(() => fakeDelay(import('../../components/Table/Table')));
const StudentTasksBox = lazy(() => fakeDelay(import('./StudentTasksBox')));

Component Wrapping for StudentTasksBox:

</pre>
<pre>
<Suspense fallback={Loading table...}>
<Table
data={tableData}
columns={tableColumns}
columnSearchMode={'dropdown'} // Can be 'none', 'input', or 'dropdown'
dropdownOptions={dropdownOptions}
headerCellStyle={{background: "#f2f2f2"}}
// ... other props
/>
</Suspense>
</pre>

Component Wrapping for of the StudentTasksBox:

<pre>
<Suspense fallback={Loading Task box...}>
<StudentTasksBox
duties={duties}
revisions={taskRevisions}
studentsTeamedWith={studentsTeamedWith} />
</Suspense>
</pre>

As shown above, we gave a JSX tag to the fallback prop to indicate what should be rendered until the component has finished loading.

As a result of these changes, the StudentTasksBox and Table components are not loaded by the application until the user navigates to the student_tasks page, meaning the user will experience faster initial load times, decreased browser memory usage, and may experience less network bandwidth if the entirety of the application isn't visited in a given session.

== Current View ==

== Implementation ==

=== Prerequisites ===
React.js
Typescript

Fork from this repo:
 
https://github.com/ychen-207523/reimplementation-front-end 
https://github.com/expertiza/reimplementation-back-end 

Please follow the video instructions for the setup of the project given in the README in the backend repository.

=== Connecting Reimplementation Frontend and Reimplementation Back end ===
After setting up remote interpreter, run below commands in bash:
<pre>
bundle install

rake db:create

rake db:migrate

rails s -p 4000 -b '0.0.0.0'
</pre>
Now run below commands in terminal for backend:
<pre>
mysql -u dev -pexpertiza

use reimplementation_development;
</pre>
After this run insert commands:
<pre>
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW())
</pre>
Now open a terminal, run below cmd:
<pre>
rails console

BCrypt::Password.create('password123')
</pre>
Copy output of above cmd in some file.

Run below command in backend:
<pre>
INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);
</pre>
To run React.js (Frontend) from VS Code:

In the project directory, you can run:
<pre>
npm start
</pre>
Runs the app in the development mode.
 
 
<pre>
npm test
</pre>
Launches the test runner in the interactive watch mode.

 
<pre>
npm run build
</pre>
Builds the app for production to the build folder.

 
Open http://localhost:3000 to view it in the browser.

Login details: admin (password123)

In case it doesn’t work: Try deleting the rsa_keys.yml file in ruby mine and try login again.

== Future Scope ==
As mentioned in the CHANGES section, we used test data for our tables. The data is called from a JSON file in the same folder as our Student Task UI src/pages/StudentTasks/assignments.json.

In order to call data from the SQL server running on the backend, we need to retrieve it using API endpoints. Some of tables may need added or deleted columns to appropriately coincide with the current table column structure.

Moreover, some of the imports and API calls are already coded into src/pages/StudentTasks/StudentTasks.tsx but not complete as it was not necessary for merely changing the front end portion of the project.

useAPI import commented out:

<pre>

// StudentTasks.tsx

// Removed useAPI import as it's currently not needed for JSON data. Uncomment when fetching data from an API.
// import useAPI from "hooks/useAPI"

</pre>

We will likely need to create a constant that coincides with an API call to the assignments table, and make sure that table has all the necessary columns.

<pre>

// StudentTasks.tsx

const StudentTasks = () => {
// These hooks can be uncommented and used when integrating API calls
// const { error, isLoading, data: studentTasks, sendRequest: fetchStudentTasks } = useAPI();
// const { data: coursesResponse, sendRequest: fetchCourses } = useAPI();

const duties = testData.duties;
const taskRevisions = testData.revisions;
const studentsTeamedWith = testData.studentsTeamedWith;

// Commented out useEffect for fetching student tasks from an API. Uncomment when needed.
/*
useEffect(() => {
fetchStudentTasks({ url: '/assignments' }); // Verify this is the correct endpoint
}, [fetchStudentTasks]);
*/

</pre>

Making sure the data being called is from the SQL server is likely more complicated since it is an API call vs a direct call to a local file. The constant tableData will likely need to be altered in a way that allows for proper fetching of data via the API.

<pre>
// StudentTasks.tsx

// Memoize the table data to use assignments from testData
const tableData = useMemo(() => testData.assignments, []);
</pre>

Finally when calling data from the SQL server, we’ll likely need to handle errors of the API calls.

<pre>

// StudentTasks.tsx

// Render the component with the Table component and necessary controls
return (
<div className="student-tasks">
<Container fluid className="px-md-4">
{/* Uncomment and adjust error handling when integrating with API calls
{error && <div className="alert alert-danger" role="alert">{error}</div>}
*/}
<Row className="mb-2">
<Col>
<h2>Assignments</h2>
</Col>
</Row>
// ...rest of table rendering

</pre>

== Team ==