Skip to content

v1.0

Latest
Latest

Choose a tag to compare

View all tags
@SilvaCastillo SilvaCastillo released this 26 Oct 17:06
· 13 commits to main since this release
v1.0
6a919f3
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode.

Release v1.0

Preparatory Work

Before delving into the details of requirements 1 and 2, it's worth mentioning that I undertook the following actions as part of my preparation:

  1. Code Comments: I thoroughly reviewed both the backend and frontend code, ensuring that all relevant sections were clearly documented with comments. This improved code readability and comprehensibility for myself and other developers who may work on the project in the future.

  2. Code Refactoring: In the 'database' and 'models/tickets' files, I conducted extensive refactoring to enhance the code's structure. This helped organize and consolidate the code, making it more maintainable for future development.

  3. URL Handling: I relocated URL references from both backend and frontend files to a separate file called 'utils.js.' This step contributed to a more structured project and simplified maintenance. The URL in 'utils.js' can now be customized based on whether I'm working locally or on a live server, ensuring flexibility in different environments.

  4. Removal of Unused Code: I identified and removed unused code in the 'utils.js' file. This resulted in a cleaner and more efficient codebase.

  5. Elimination of Unused Imports: I reviewed the project's files and removed import statements that referred to files no longer in use. This cleanup improved the project structure and code consistency.

  6. .env File: To enhance project security, I removed the '.env' file from the backend repository. This was a crucial step to prevent the exposure of sensitive information.

  7. Quality Assurance with 'npm run lint': Before implementing requirements 1 and 2, I used 'npm run lint' to ensure that the code adhered to a high standard of quality and consistency. Any code clashes or shortcomings were addressed.

  8. PropTypes for Enhanced Prop Validation: To bolster the codebase's robustness and clarity, I added PropTypes to improve prop validation in the project. This step facilitated troubleshooting and helped avoid potential issues.

With these actions as a foundation, I was ready to tackle requirements 1 and 2 and build upon the improved codebase.

Requirement 1

Part 1: To fulfill requirement 1, I added an if statement in my frontend API file to check if the received objects have the 'FromLocation' and 'ToLocation' attributes. Initially, I attempted to handle this on the backend, but it proved challenging to implement satisfactorily. Thus, I opted to continue handling trains without 'FromLocation' and 'ToLocation' attributes in the objects. This allows us to potentially address these cases more effectively in the future.

Part 2: To fulfill requirement 1, I needed to make changes so that clicking on a train's info displays only that specific train on the map and in the list. Clicking again should show all trains once more. To achieve this, I introduced the following variables: positionData, shouldRenderContent, filteredMarkers, and filteredTrains. I also created the handleSelectTrain function, which is used when clicking on a train in the list. Depending on the value of shouldRenderContent, the function alters what should be displayed. If shouldRenderContent is true, all trains are shown, and if false, only the selected train is displayed. Working alone made this task somewhat challenging, but I managed to implement these changes.

To display the correct trains and markers, I utilize the trainsToShow and markersToRender variables. If shouldRenderContent is true, all trains and markers are displayed; otherwise, only the filtered trains and markers are shown. I also check for duplicate train data to avoid displaying the same train twice.

Requirement 2

To fulfill requirement 2, I made the following changes:

  1. Introduction of GraphQL to the Backend: This required a significant restructuring of existing code to adapt it to the GraphQL data model.

  2. Integration of Apollo Client on the Frontend: I integrated Apollo Client to fetch data from the GraphQL backend and ensure data is displayed as before.

  3. Removal of the Old API File from the Frontend: Since GraphQL is now exclusively used for data retrieval, I removed the old API file from the frontend.

  4. Organizing GraphQL Requests and Mutations: I created a new file in the 'utils' folder in the frontend called 'queries' to organize all the GraphQL requests needed to fetch data from the GraphQL backend or perform mutations, such as creating a ticket.

Assets 2
Loading