Bluebird Transport Management System - Frontend Part
Frontend
Tech Stack
React, TypeScript, Refine
Type
Project
Client
Bluebird
Categories
Frontend
The Bluebird Transport Management System is a comprehensive web application designed to streamline the management and administration of a package shipment operations. The frontend application is built using React and TypeScript. This project delivered to one of the biggest public taxi transportation vendor in Indonesia that is going to expand their business domain into package shipment services. The frontend application is designed to be scalable, maintainable, and easy to use.
Key Features
Dashboard
Allows user to monitor the performance of transactional data, the charts shown are using recharts library.
Multi Application
One frontend project to host 2 mode application that serve different menus based on selected logged in application mode. The modes available is Headquarter mode and Branch. The headquarter focus on managing masterdata including master branche, and monitoring transactional data. The branch focus on managing order transaction and managing package transition between first mile, middle mile, and last mile.
Order Transaction and Transition (First Mile, Middle Mile, and Last Mile)
The form which the transaction came from, branch users will fill the form with the package information and the package will be processed later in different menus in branch mode application. The delivery process includes a first mile, an optional middle mile, and a last mile.
Airwaybill Information Printing
The airwaybill information printing feature allows users to print the airwaybill information for a specific package. The airwaybill information includes the package details, such as the package airwaybill number, the package sender and receiver, and the package weight. This feature utilize react-to-print package to convert rendered react dom to be inside an iframe and then print that iframe.
My Involvement
Technical Contributions
- Architecting the project by using Refine framework with directory structure below:
- Directing which package to use for specific case (e.g. react-to-print for printing airwaybill).
- Directing how validation should be done in the frontend by utilizing Joi package.
- Directing how component files should be structured for a clear and maintainable code by separating service and application. The service is handling API calls and application is handling the service calls. So if later http client need to be changed, the component will not be affected.
- Directing how tslint rules should be configured in this project by following Bluebird standard tslint rules.
- Do bug fixing.
.
├── .husky/ # Git hooks to ensure code quality before commits
├── cypress/ # Cypress directory for end-to-end tests
│ ├── component/ # Component tests
│ ├── fixtures/ # Mock data for testing
│ ├── support/ # Cypress utilities and configuration files
│ ├── utils/ # Helper functions for tests
├── public/ # Directory for static files (icons, images, etc.)
├── src/ # Main source code directory
│ ├── app/ # Application entry point
│ ├── assets/ # Static assets like images, icons, etc.
│ ├── components/ # Reusable UI components
│ ├── config/ # Application configuration files
│ ├── context/ # Global context using React Context API
│ ├── hooks/ # Custom hooks for application logic
│ ├── modules/ # Main application modules
│ ├── pages/ # Application pages
│ ├── providers/ # Context or state providers
│ ├── utility/ # Utility functions for the application
│ ├── index.tsx # Main entry file for the React application
├── Dockerfile # Docker configuration file for creating containers
├── index.html # Main HTML file for the application
├── package-lock.json # Lock file to ensure consistent dependencies
├── package.json # Project metadata and dependency list
├── postcss.config.js # PostCSS configuration for CSS processing
├── README.md # Project documentation
├── tailwind.config.js # Tailwind CSS configuration
├── tsconfig.json # TypeScript configuration for the main project
├── tsconfig.node.json # TypeScript configuration for Node.js
└── vite.config.ts # Vite configuration for the dev server and build process
- Architecting the base logic of API data provider and authentication provider.- Directing which package to use for specific case (e.g. react-to-print for printing airwaybill).
- Directing how validation should be done in the frontend by utilizing Joi package.
- Directing how component files should be structured for a clear and maintainable code by separating service and application. The service is handling API calls and application is handling the service calls. So if later http client need to be changed, the component will not be affected.
- Directing how tslint rules should be configured in this project by following Bluebird standard tslint rules.
- Do bug fixing.
Non Technical Contributions
- Onboard the development team (engineer and QA) to the project.
- Led daily meetings to align team with the project timeline.
- Attend client's steering committee meetings to show the latest progress of the project and get feedback.
- Bridge client's technical requirements with my development team.
- Document the high level project overview by using C4 Diagram to let my development team understand the bigger picture of the project.
- Meet with client's technical team to coordinate for integration between client's system and my development team's system (Keycloak SSO, SAP Accounting System, Email Notification Service, and API Gateway).
- Coordinate with client's partner to integrate my development team's system to the partner system (KGX API Shipment Integration).
- Led daily meetings to align team with the project timeline.
- Attend client's steering committee meetings to show the latest progress of the project and get feedback.
- Bridge client's technical requirements with my development team.
- Document the high level project overview by using C4 Diagram to let my development team understand the bigger picture of the project.
- Meet with client's technical team to coordinate for integration between client's system and my development team's system (Keycloak SSO, SAP Accounting System, Email Notification Service, and API Gateway).
- Coordinate with client's partner to integrate my development team's system to the partner system (KGX API Shipment Integration).
Project Notes
What I Learned
- The React Hook is re-rendering a lot when using refine with a large scoped application, this is a major issue in this project. Maybe in the next project we will embrace Zustand.
- Refine was used to speed up UI integration, but later we integrated to the client's owned design system called Kitbird, so not all Refine features are used, but Refine still speeding up development by helping building the project boilerplate, data provider, authentication provider, and authorization provider.
- React Query was not fully utilized in this project, every react query calls wrapped into a basic promise because of the concept of separation between service and application. This is actually an added effor for handling query failures and caching, so later in the next project i will focus on full utilization of React Query.
- The unit tests developed by developers are not pointing to certain class name or id, if Kitbird changed the class name or id, the unit tests will break. So later in the next project class name or id must be persisted in standard format inside base form field components.
- Refine was used to speed up UI integration, but later we integrated to the client's owned design system called Kitbird, so not all Refine features are used, but Refine still speeding up development by helping building the project boilerplate, data provider, authentication provider, and authorization provider.
- React Query was not fully utilized in this project, every react query calls wrapped into a basic promise because of the concept of separation between service and application. This is actually an added effor for handling query failures and caching, so later in the next project i will focus on full utilization of React Query.
- The unit tests developed by developers are not pointing to certain class name or id, if Kitbird changed the class name or id, the unit tests will break. So later in the next project class name or id must be persisted in standard format inside base form field components.