React.js problem creation [Project Based Front-end]

Created by DoSelect Content Devs, Modified on Tue, 25 Mar at 7:04 PM by DoSelect Content Devs

This guide provides a structured approach to developing, testing, and documenting frontend problems using React.js on the DoSelect Platform. It outlines the project structure, test case implementation, and best practices for creating reliable and maintainable React applications.

The documentation covers:

TABLE OF CONTENTS

1. Landing on the Dashboard
2. Navigating to Problem Creation
3. Configuring Basic Problem Details (Required)
4. Setting Up the Project
5. Project Template - Using the Upload ZIP Method (Required)
- Things to Remember While Using the Project Template (React.js)
6. Project Stub (Required)
- Sanity Check (Required)
7. Project Solution (Optional)
8. Filling Remaining Problem Details
9. Finalizing the Problem
- Evaluation Details
- Action Buttons
10. Understanding the Project Structure
11. How to write a Test case?

1. Landing on the Dashboard

When you log in to DoSelect Platform, you arrive at the Home dashboard.
From here, you can manage tests and access the Library tab at the top of the page.
Action: Click on the Library tab to move to the question bank.

2. Navigating to Problem Creation

Once in the Library, you will see available libraries like DoSelect Questions and My Company Questions.
At the bottom-right corner, you will find a + (plus) button.
Action: Click on the + Create a new problem button to start creating your problem.

3. Configuring Basic Problem Details (Required)

A dialog box titled "Create New Problem" will appear.
Fill in the following fields:
- Name: Provide a concise, meaningful title (e.g., "React: Currency Converter"). Limit: 45 characters.
- Problem Type: Select Project Based: FrontEnd.
- Level: Choose Easy, Medium, or Hard.
- Framework: Choose React(18.2.0, Node14)..
Action: Click Create to proceed.

4. Setting Up the Project

You will be directed to the Problem Setup Interface. You can set up the React.js project using one of two methods:

Upload ZIP (default)
GitHub Link

5. Project Template - Using the Upload ZIP Method (Required)

Download the projecttemplate.zip from the Project Template section, or use the following link: Project Template
Modify it locally as per the problem requirement.

Things to Remember While Using the Project Template (React.js)

The downloaded projecttemplate.zip includes a sample project and setup guide in the README.md file. Replace the sample implementation with your problem-specific code.
Modify only the necessary component files inside src/pages/ based on your problem requirements.
If certain files are not relevant (e.g., API_URL.js when no API calls are needed), you should clean up and remove those to keep the project minimal.
Ensure that test cases are added within appropriate directories like src/tests or src/tests/pages. These should fully validate the required functionality of the problem. You can use the RTL library to write the test cases.
The README.md should be written and aligned with the problem description and test expectations. Avoid any mismatch or ambiguity. There are instructions regarding the environment and IDE in the template README. Modify or remove them only if required.
Ensure that the relative paths of test files are added correctly to the read_only_files array in configuration.json.
Any files you want the candidate to see or edit by default (e.g., App.jsx, MainComponent.jsx) should be listed with proper paths under default_open_files.
Do not modify or delete platform-required configuration files like pubic/; webpack.config.js, package.json or jest.config.js.
Before zipping the project:
- Exclude generated folders such as node_modules, build outputs, logs, and caches, .DS_Store, and other system files, i.e., files added in .gitignore.
- Verify that the zip structure does not contain a nested parent folder—project files should exist at the root level of the zip.

6. Project Stub (Required)

This is the version of the project with key logic removed which will be given for the candidates to fill in the required logic.
Create the .zip as mentioned above and upload it here. (max 5MB).
The Open in Editor option allows you to view/edit the stub in the online editor.
It is recommended to add comments for the candidates where they have to add the code.

Sanity Check (Required)

Ensures the stub is valid and will run:
- ZIP file < 5MB
- Extracted contents < 20MB
- Proper structure & valid config format.
- Test cases fail and the score is zero. (This will take time as the project is run for evaluation).
It will run automatically on file upload. If it fails you can make the changes using the Open in Editor option to modify. Then rerun the sanity using the play button.

7. Project Solution (Optional)

Enable this to upload the fully working solution for reference.
Upload the complete version of your modified project (with logic) for reference.
Run the Sanity Check to verify everything compiles and works as intended.
Although this section is optional, it is recommended to upload a solution for accurate validation and reference.

8. Filling Remaining Problem Details

Some details (like name and level) are already set but can be edited here.

Problem Name (Optional)

Modify the title if necessary. This is what the candidate will see.

Expected Solving Time (Required)

Indicate how long the candidate should take (e.g., 60, 90, 120 minutes).

Description (Required)

This is the problem statement shown to candidates.
Should include:
- Task Requirements
- Context/use-case
- Expected UI functionality

Difficulty Level (Optional)

Easy: Static forms or basic hooks
Medium: Dynamic rendering, props/state, reusable components
Hard: API integration, advanced state management, routing

Scoring (Optional)

Set the score (e.g., 75).
Penalty does not apply to project-based problems. Leave it at 0.

Maximum Re-Submissions (Optional)

Recommended to set to 0 (unlimited submissions).

Tags (Optional)

Discovery Tags: Used for filtering/discoverability in your library (e.g. : Component Design, Routing)
Insight Tags: Used for analytics (e.g.: State Handling, API Fetching)

Attachments (Optional)

Add relevant or related resources for better problem clarity. This section is completely optional. Examples include:
- Include a GIF to showcase the expected UI flow.
- Reference documentation.

9. Finalizing the Problem

Evaluation Details

Displays evaluation mode and score.
For React problems, the default is Automated Testing Framework.

Action Buttons

Save Problem: Saves your work. Is disabled if all the required fields are not added.
Save and Clone: Duplicates the current problem. Is disabled if all the required fields are not added.
Lock/Unlock: Locks the problems to avoid accidental edits. Unlock it for making any changes.
Archive Problem: Deactivates the problem.
Try This Problem: Opens the test view for trial.
Problem Analytics: Shows problem performance metrics.

Note: Ensure all required fields (marked with a red asterisk *) are filled. Otherwise, the problem will remain incomplete and cannot be used in tests.

10. Understanding the Project Structure

This structure follows a common pattern for React applications, efficiently organizing the source code, configuration files, and test cases.

1. Public Folder (public/)

(Not to be changed)
Purpose: Provides static assets, including the main index.html file, where the React app is mounted.
Requirement: Must include index.html with a root <div id="root"> for rendering React components.

2. Source Folder (src/) - Main directory for application code

2.1 Pages Folder (src/pages/ or src/components/)

(To be changed)
Purpose: Organizes different page components in the application.
Requirement: Contains reusable and structured components for page-level rendering. Remove the existing components and add the components for your project.

2.2 API Configuration (src/API_URL.js)

(Not to be changed)
Purpose: Stores API endpoint URL and helper functions for making API requests.
Requirement: This should be kept in API-related projects where JSON-server is used. It will create the API_URL for the environment.

2.3 Styles (src/App.css)

(To be changed)
Purpose: Defines global styles used across the application.
Requirement: Should maintain a clean and structured CSS layout without unnecessary styles.

2.4 Main Application Files (src/App.js)

(To be changed)
Purpose: The main React component serves as the entry point for rendering other components.
Requirement: This should include essential imports and the root component structure without unnecessary logic.
Note: For routing problems, set BASE_PATH as below to ensure the routing works in the browser.

<Router basename={BASE_PATH}>

2.5 Index File (src/index.js)

(Not to be Changed)
Purpose: The root JavaScript file where ReactDOM renders the app into index.html.
Requirement: Should properly import App.js and any required dependencies for React rendering.

3. Tests Folder (tests/pages/)

(To be changed)
Purpose: Stores unit and integration test files for different pages.
Requirement: Test cases should be properly structured using Jest and React Testing Library to validate the expected functionality of components.
A sample test case has been given in the document below. You can refer it for writing your test cases.

4. Configuration & Environment Files

.babelrc
- (Not to be changed)
- Purpose: Configures Babel to enable modern JavaScript features.
- Requirement: This should be properly configured to support the project's required JavaScript versions.
.gitignore
- (Not to be changed)
- Purpose: Specify files and folders to ignore in Git to prevent unnecessary tracking.
- Requirement: Must include node_modules, build files, and sensitive environment variables.
configuration.json
- Purpose: Stores project-related configuration settings.
- Requirement: Should contain only necessary configuration values to avoid unnecessary complexity.
  - Editable Sections:
    - Default_open_files
    - Purpose: Defines which files open automatically when the environment starts.
    - Requirement: Add or modify file paths to ensure candidates begin with the most relevant files
  - Read_only_files
    - .Purpose: Specifies files that cannot be modified to maintain integrity.
    - Requirement: Update this list to include essential configuration and test files that should remain unchanged.
  - Non-Editable Sections
    - buttons, scoring, post_start, and preview_port must remain unchanged, as they control the environment setup and execution.
- For more details, refer to this.
db.json
- (To be changed)
- Purpose: Used for mock data or a local JSON server. Add the mock API data here. Refer to this for more details.
- Requirement: This file should be included only in the projects where mock API is required.
jest.config.js
- (Not to be changed)
- Purpose: Defines configurations for Jest testing.
- Requirement: Should not be modified unless necessary for specific test setup requirements.
package.json
- (Not to be changed)
- Purpose: Contains project metadata, dependencies, and scripts for building and running the React app.
- Requirement: Must be correctly configured to include necessary dependencies and scripts for smooth execution.
README.md
- (To be changed)
- Purpose: Provides documentation for project setup, usage, and guidelines.
- Requirement: This should be updated with relevant information about the project.
webpack.config.js
- (Not to be changed)
- Purpose: Configures Webpack for bundling and optimizing the React application.
- Requirement: This should be properly set up to optimize performance and include necessary loaders and plugins.

11. How to write a Test case?

This section explains how to write test cases. For example, we have used the test case for the MainPage component using Jest and React Testing Library.

Overview

The test file ensures that:

The MainPage component renders correctly.
A specific heading is visible on the screen.
Clicking a link navigates to the correct route.

Imports

import React from 'react';
import '@testing-library/jest-dom'
import { fireEvent, render, screen } from '@testing-library/react';
import MainPage from '../../src/pages/MainPage';
import { BrowserRouter } from 'react-router-dom';

React: Required for rendering React components.
@testing-library/jest-dom: Provides Jest matches for better DOM assertions.
render, screen, fireEvent (from @testing-library/react):
- render(): Renders the React component.
- screen.getByText(): Finds elements by their text content.
- fireEvent.click(): Simulates a user clicking an element.
MainPage: The component under test.
BrowserRouter: Wraps the component to support React Router functionalities.

Test Suite

describe('MainPage testcase', () => {

Groups-related tests for MainPage.

Test Case 1: Checking the Heading

it('should display heading in the screen', () => {
    render(
        <BrowserRouter>
            <MainPage />
        </BrowserRouter>
    )

    const desiredText = screen.getByText("Hello from DoSelect")
    expect(desiredText).toBeVisible();
})

Steps:

Render the MainPage component inside <BrowserRouter>.
Find the text "Hello from DoSelect" using screen.getByText().
Assert that the text is visible on the screen using expect(...).toBeVisible().

✅ Ensures that the heading is correctly displayed.

it('should route to another-page', () => {
    render(
        <BrowserRouter>
            <MainPage />
        </BrowserRouter>
    )

    const anotherPageLink = screen.getByText("Learn More");
    fireEvent.click(anotherPageLink);
    console.log('path: ', window.location.pathname);
    expect(window.location.pathname).toBe(`${BASE_PATH}another-page`)
})