iturres / iturres-reactive-portfolio Goto Github PK

Overview:

In this issue, I will outline the migration plan for converting functional components written in ES6 arrow function syntax to ES5 function syntax within this project's React application.

Motivation:

The motivation behind this migration stems from the need for improved compatibility, readability, and debugging capabilities within this project's React codebase. By transitioning from ES6 arrow functions to ES5 function syntax, I aim to enhance the maintainability and accessibility of the code, particularly for developers who may be less familiar with ES6 features.

Benefits of Migration:

1. Improved Compatibility: ES5 function syntax has broader compatibility with older browsers and environments compared to ES6 arrow functions. This ensures that the code remains functional across a wider range of platforms without requiring transpilation.

2. Enhanced Readability: Some developers find ES5 function syntax clearer and easier to understand, especially those who are less familiar with ES6 features. The function keyword explicitly defines a function, making it more apparent where the function begins and ends.

3. Simplified Debugging: ES5 function syntax may make debugging easier in some cases, as function names are explicitly declared, aiding in stack traces and error messages. Additionally, when using React DevTools, arrow function components appear as anonymous functions, making it challenging to identify them during debugging. By migrating to ES5 function syntax, functional components will have explicit names, improving the clarity and ease of debugging within React DevTools. This enhancement streamlines the debugging process and enhances developer productivity by providing clearer insights into component hierarchies and interactions.

Proposed Steps:

1. Identify Components: Begin by identifying functional components within the React codebase that are currently written using ES6 arrow function syntax.

2. Convert to ES5 Syntax: For each identified component, refactor the code to use ES5 function syntax instead of arrow functions.

By following these proposed steps, I can successfully migrate the functional components to ES5 function syntax within this project's React application, thereby improving compatibility, readability, and debugging capabilities.

Status

The portfolio has some critical accessibility issues that must be addressed.

Tools for the job

• Google Lighthouse.
• Contrast Checker.

Areas to focus on:

• Semantics.
• Text Contrast.
• Links.
• Labels.
• Aria live regions.
• Programmable focus management (investigate further).

Notes:

• Navbar toggle needs a clear role and keyboard focus.
• Announce toggle state (open/close) to assistive technologies.

Possible changes

Content

• List of skills: Showcase which tools and technologies you’re familiar with (and any other skill).
• Contact details: email address.
• Call-to-action (CTA): There is at least 1 CTA that brings the user to the “contact” section.
• Update form placeholders.

Personal Extra ones

• Update the Apple icon.
• set ENV at repo settings and add deploy file.
• re-deploy.

Rubric

Description:

Issue: 1. When the user goes to the ProjectsPage, and the projects are rendered along with their respective LikeButton component, each of these like buttons triggers a request to the involvement API to get all the likes, i.e. 18 requests for the same likes array.
Issue: 2. When the user likes a project, this will too trigger a new request to fetch all the likes, again, a redundant network request.

Steps to Reproduce:

1. Open the application.
2. Navigate to the 'Projects' page.
3. Open DevTools' Network tab and refresh the projects page.
4. Observe the redundant multiple requests for each project's likes (refer to 'likes/' requests).

Expected Behavior:

Only one request should be made to retrieve all current project likes.

Actual Behavior:

Each 'LikeButton' component triggers a request for the entire likes array. Consequently, there are -18 unnecessary requests- totalling 19 requests for all projects.

Proposed Solution:

Issue 1:

Since fetching each project's likes by ID is not currently supported by the Involvement API, alternative approaches are required.

I propose fetching the total likes in the parent container. Since this involves fetching the likes at the most parent node, which in this case is 'ProjectsPage', I suggest the following three potential solutions for handling the data thereafter:

• A. Pass the data down the component hierarchy to every button. The prop flow would be: ProjectsPage => SplideCarousel => SplideCarouselSlide => LikeButton.

• B. Store the likes in localStorage at 'ProjectsPage' for subsequent retrieval in each 'LikeButton'.

• C. Implement Redux: dispatch an action to store all the likes.

Regardless of the chosen approach, each 'LikeButton' will need to filter the likes array to retrieve the likeCount corresponding to that project ID. Alternatively, an additional reducer could be set up to obtain the like count for each project ID.

Issue 2:

The issue described in the description occurs within the handleLikeSubmit async function. I suggest removing the invocation of the updateLikeCount async function.
Currently, at line 83, we flip the boolean value of the local state variable wasLiked to true to apply the desired styles and provide user feedback that their like has been set. To allow the user to continue liking the project and see the count increase, we need to do the same within the conditional at line 86 to reset this variable to false. This will trigger setLikeCount again.
Also, rename the functional argument liked with wasLiked when setting the new state.

Note:

❗This issue is critical as it significantly affects the efficiency and performance of the application by causing redundant network requests for project likes.

Update Projects json data

• Add all rails project data.

• Add all project screenshots.

• Improve any UI that needs improvement.

• re-deploy from development once PR has been merged.

• **Custom 404 Page component for Better UX: ** At the moment when the user uses the URL bar and hard enters a new path, it will trigger the 404.html page that will refresh the page redirecting the user to the portfolio root path aka accessPage i.e /iturres-reactive-portfolio/ path. This is fine but a custom not found page will be better UX.

• Migrate from BrowserRouter to HashRouter: Basically, when deploying with gh-pages, the wildcard (*) won't work, if the user goes to an unsupported URL the NotFoundPage component WILL NOT render, instead, GitHub pages default 404 page will show up. To support the redirection to the custom 404 component, we need HashRouter's technology to render after triggering the wildcard char to route all requests to the index.html.

The current behaviour is the following, once the user fills out the whole contact form, it will proceed to click submit, if all the validations are correct, it sends the data to the server and renders a 'Thank you' message in the submit button.

I want to also render a small alien waving hello next to the thank you button, or even better, within the button.

Overview:

In this issue, I will outline the migration plan for converting functional components written in ES6 arrow function syntax to ES5 function syntax within this project's React application.

Motivation:

The motivation behind this migration stems from the need for improved compatibility, readability, and debugging capabilities within this project's React codebase. By transitioning from ES6 arrow functions to ES5 function syntax, I aim to enhance the maintainability and accessibility of the code, particularly for developers who may be less familiar with ES6 features.

Benefits of Migration:

1. Improved Compatibility: ES5 function syntax has broader compatibility with older browsers and environments compared to ES6 arrow functions. This ensures that the code remains functional across a wider range of platforms without requiring transpilation.

2. Enhanced Readability: Some developers find ES5 function syntax clearer and easier to understand, especially those who are less familiar with ES6 features. The function keyword explicitly defines a function, making it more apparent where the function begins and ends.

3. Simplified Debugging: ES5 function syntax may make debugging easier in some cases, as function names are explicitly declared, aiding in stack traces and error messages. Additionally, when using React DevTools, arrow function components appear as anonymous functions, making it challenging to identify them during debugging. By migrating to ES5 function syntax, functional components will have explicit names, improving the clarity and ease of debugging within React DevTools. This enhancement streamlines the debugging process and enhances developer productivity by providing clearer insights into component hierarchies and interactions.

Proposed Steps:

1. Identify Components: Begin by identifying functional components within the React codebase that are currently written using ES6 arrow function syntax.

2. Convert to ES5 Syntax: For each identified component, refactor the code to use ES5 function syntax instead of arrow functions.

By following these proposed steps, I can successfully migrate the functional components to ES5 function syntax within this project's React application, thereby improving compatibility, readability, and debugging capabilities.

Overview:

Migrate the portfolio project from Create React App (CRA) to Vite for enhanced development experience and improved performance.

Motivation:

Create React App has been a reliable tool for bootstrapping React applications, but with the evolution of frontend development tools, Vite has emerged as a promising alternative. Vite offers several advantages over CRA, including faster initial bundling, instant hot module replacement (HMR), and a more flexible configuration approach.

Benefits of Migration:

1. Improved Performance: Vite leverages ES module imports and native ES features for faster bundling and development server startup.
2. Faster Development: Instantaneous HMR speeds up development cycles, providing a smoother developer experience.
3. Simplified Configuration: Vite's simple and intuitive configuration reduces boilerplate and allows for easier customization.
4. Ecosystem Support: Vite has gained significant traction within the React ecosystem, with growing community support and compatibility with popular plugins and tools.

Proposed Steps:

1. Evaluation: Assess the compatibility of the project dependencies and third-party libraries with Vite.
2. Configuration: Set up Vite configuration to match the existing project setup and build requirements.
3. Migration: Gradually migrate components, styles, and configurations from CRA to Vite, ensuring functionality and performance are maintained.
4. Documentation: Update project documentation to reflect the migration process and provide guidance for future development.

For mobile we have the cool opening flower like navbar, However, I would like to develop a navbar that resembles an IDE's files tab.

• This navbar needs to be render only for Desktop version and it will contain all the portfolio pages links.
• The current navbar will contain the links to the pages only for mobile and for desktop it will only have the social media links.
• Follow VScode layout for guidance.
• This will impact the overal layout of the current project, so, make necessary changes on every stylesheet to maintain a nice and delicate design.

Implement a loading state for the LikeButton UI component.

• This feature will display a loading indicator (spinner, etc) to users while the likes are being fetched.