This gist details the decisions I made, technologies used and important design patterns for the Front End Capstone Project: Atelier
https://github.com/Idakka/Project-Atelier/
Design and implement the Ratings And Reviews widget for the Atelier FEC project for Hack Reactor Remote Part Time cohort 28
Desing and implement an Amazon s3 storage bucket and all API connections to it.
Today was the second class day of the project. I spent an hour before class reviewing the visual docs and the various components in the business doc.
The challenge is to quickly gain a 30k foot view of the entire project and plan the skeleton and first steps without getting bogged down in any details yet.
I read the documents and started copying spec files and other resources into our group Trello to keep everything in one place as the source of truth.
I felt more comfortable with our scope and workflow after reviewing docs and planning with the team.
I wanted to make sure I had a mental model for the heirarchy of the project and workflow.
I put reference to all of the spec docs into Trello as our ticket system will be the place of truth for feature, implementation, and research work.
I am much more comfortable with the skeleton of the journey we are about to embark on.
Today was spent organizing documents and researching file upload approches.
What is/are the best way(s) to upload images to our application server.
I found documentation for using formdata with both axios and regular browser methods.
I felt comfortable on starting to implement the file upload methods and components.
Today was spent investigating the 4 major widgets of the app. We did a classtime workshop and split off to plan within the team.
Who will be responsible for which component? What are the first steps to get a skeleton rendered?
I made a basic component and pushed the commits and made a pull request.
I felt comfortable on starting to implement the file upload methods and components.
I wanted to get a skeleton with all div/elements and sub-components represented and get it rendered on the browser.
I made an outline of all html elements over the visual example we were given with relative nexting represented by different colors.
I initially had a bug preventing render caused by some confusion about naming convention for our different components. I sent a slack message and we arrived at PascalCase and so I added that to my commit. I should have separated this debugging concern out but I needed to fix it for anything else to work. I'll only stage the files needed for that one concern going forward to keep commits and PRs granular.
I worked on rendering more aspects of the Ratings and Reviews component as well as getting Mock Data from the API using Postman and including it in the client side of the app.
I wanted to import the star-review component that Milo created and make sure I understand how parameters are passed in and handled.
Put the star review component into the appropriate div and passed a hard coded value as a placeholder.
Since the component already had div classNames and data-testid, there were redundant nesting of divs and the test suite broke. I removed the encapsulating divs from the top-level component and will continue to do so as I add sub-components. It will also be helpful to create the remaining components with react fragments to reduce the nested div clutter going forward.
I wanted to put a mock version of the various API GET query returns in the client side so all of the devs can use that to mock up the rendering of their components. It is also important to not keep querying the APIs since there are rate limits and we have already hit them before during development.
I added mock data for all of the API GET requests. The data is currently imported into ProductDetailPage.jsx in the same data type as it returns from API GET requests (array/object). This is a temporary measure just to get the client passing the data in without constantly hitting the external API. I also created several tests for mock data types.
The data is being passed into a console.log statement and the tests are are currently directly accesssing the data exports from the folders structure. I want to refactor the mock data using jest or another API mock suite to accomplish testing the handling of data via API calls without overtaxing the API limits.
Today was spent deciding on short-term solution to state management. The entire cohort had a QnA session and passed ideas around about different approaches.
The primary options are:
Our main work was to get all PRs having to do with mock data and API requests merged so everyone can start passing state to their components.
We decided on putting the mock data at the client level for now. If the route already exists in the server, then leave it, but we'll put an alternate server mock next week after MVP demo.
We are getting data into the components that are setup to handle it and have a unified source of truth for the current structure.
Trello ticket creation and Amazon s3 setup.
I spent time making more detailed Trello tickets and drilled down into implementation level tasks
I copied the spec into the about section of the tickets and imagined the scope of each aspect of the tickets to decide if I needed to break the task down into more implementation tickets.
I feel I have a better grasp on the scope of my widget and how the tasks are going to be broken down.
Investigate S3 storage and how to retrieve urls to send to Atelier API
read S3 documentation and created a bucket. REST API endpoints are at s3-website-us-east-1.amazonaws.com with a bucket name "hr-nylon-eric-fec-bucket"
I setup an account and successfully uploaded an image to the s3 bucket.
Added Modal component for Review form S3 bucket multiple file upload
Get S3 route working as well as temporary storage of uploaded files on the client.
I got single files working but was searching for a good solution to multiple file upload. Found a clever solution using generated local URLs to keep reference and load photos into the preview window.
https://medium.com/@650egor/react-30-day-challenge-day-2-image-upload-preview-2d534f8eaaa
I got the files to upload to the state array in the component. The display still needs to be worked on and I'll have to create a component(s) to display and map the 1-5 photos for preview.
Finish basic Modal form for Review uploads.
I borrowed the patterns from the stateful class-based modal in the Overview module. I had to copy some interesting click handlers and deal with how they will work nested in a new component.
The basic form is rendering and I understand how the visible/invisible state is handled at the tope ProductDetailPage level. It is important to pay close attention to "this" identity as props and event handlers are being passed from one class-based stateful component to another for this modal functionality.
Deploy all the things! http://frontendcapstone.com
Get repo onto AWS instance and connect through a persistant IP or domain name
deploy! set up domain frontendcapstone.com w/ google domains (domains.google.com)
https://aws.amazon.com/ec2/getting-started/
set up security policy on AWS EC2 I started with everything open and then restricted to port 80 UDP/TCP traffic for incomming. I also openned ICMP traffic for pinging purposes as well as ssh port 22 for logging into server.
set up elastic IP so it will persist after reboot/termination. you have to associate it to the instance from the elastic IP tab
Linux/UNIX instance:
ssh from local:
set permissions to pem file:
chmod 400 hr-nylon-eric.pem
ssh -i hr-nylon-eric.pem ec2-user@ec2-35-172-51-196.compute-1.amazonaws.com
Then navigate to and create folder for project:
git clone https://github.com/Idakka/Project-Atelier.gitsudo yum install git
This is a special Node build for AWS instances. Don't use standard Yum/apt install.
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash
nvm install node
. ~/.nvm/nvm.sh
node -e "console.log('Running Node.js ' + process.version)"
npm install -g npx
sudo amazon-linux-extras install nginx1sudo service nginx start
cat /etc/nginx/sites-available/default
sudo nano /etc/nginx/nginx.conf server { listen 80; server_name tutorial; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_pass http://127.0.0.1:3000; } }
sudo service nginx restart
npm install webpack
npm start
npm i -g pm2
pm2 start tutorial/index.js
pm2 startupsudo env PATH=$PATH:/home/ec2-user/.nvm/versions/node/v16.4.0/bin /home/ec2-user/.nvm/versions/node/v16.4.0/lib/node_modules/pm2/bin/pm2 startup systemd -u ec2-user --hp /home/ec2-usersave config with everything running (no nginx at this point)
pm2 save
pm2 start nodemon server/server.js
That’s it! You can log out/in to SSH, even restart your server and it will continue to run on port 80.
pm2 lssystemctl start nginx
systemctl enable nginx
having trouble restarting nginx on reboot,
sudo systemctl enable nginx
I got the app deployed pretty quickly but had to troubleshoot making the node server and nginx reverse-proxy persist after reboot.
get inputs validated during entry.
Found approaches and landed on html validation on inputs with validation functions called on upload.
The basic validation options were pretty simple and effective. The next step would be to do some conditional styling like red outlines and UI feedback when users enter disallowed text.
Solve issues with the form elements not re-rendering on state change. This was particularly noticeable with the radio button as the button was one change behind. I also noticed that console.log of the state in every case was behind the actual state.
I researched several articles and found 2 important concepts:
Every change in radio button/ text field updates state and re-renders the form view. You can also pass a callback as a second argument to setState(state, () => {}); and perform operations after the async change.
Get initial google page speed.
Pulled down latest main branch on AWS deployment and built/transpiled newest changes. Results:
The results on desktop were middling at 73/100. Big issues are size of payload/bundle.js file as well as full size images being loaded. The results on mobile are worse at 23/100 especially because of the larger image sizes. We are working on using lazy loading as well as image compression to deal with these issues. It would also be good to limit image upload sizes and have a resolution conversion at the server for images that get uploaded via our routes to s3 storage.