Hack Reactor | BOC | Journal Entry 2
Categories: hack reactor BOC
Overview
Creating the ArtistProfile component for the SoundCrate app
Challenge/Motivation
This component will show a user's profile picture, name, a short bio, and will map over the user's tracks and display them below. If a user is looking at their own profile, it will also have an edit button, allowing the user to navigate to the view for updating and editing their profile.
Actions Taken
When the skeleton for this component had been created, it was being rendered directly in the the other components that needed access to it. Because we decided to have the main App component handle all of the conditional rendering for any "main" view (view that takes up the full page, minus the TopBar and NavBar) I decided to move the component outside of the components that were rendering it separately.
Because there was also another component being rendered similarly (the Play component that displays for the user to listen to a track) I moved them both up to the App component simultaneously.
To do so, I had to create useState variabels in the App component for both artistData and songData as well as the setSongData and setArtistData functions. I also had to create handler functions that would be passed down to the child components (such as any view that is showing a SongCard where the user can click on an artist name or a song name) to allow them to pass data back up to the state here in App upon clicking a related link.
Results Observed
I believe a structure where the main App component houses most of the necessary data and functions and then passes it down to the child components is the cleanest way to handle the rendering and data of the main views. I'm looking forward to the database-related stuff being finished so we can start to use the actual database data in our components, and I think it will allow us to more easily develop the components we are responsible for.
Hack Reactor | BOC | Journal Entry 1
Categories: hack reactor BOC
Overview
Researching and creating a custom theme with Material UI
Challenge/Motivation
The app our team was tasked with building is SoundCrate, which is a TikTok-esque audio recording and collaboration app. It needs to have cohesive component style and structure based on the wireframe and requirements of the client, and we decided to use Material UI for rapid development.
Actions Taken
I started by doing some research on Material UI and theming best practices, and put together a palette based on our initial Proto.io design. Although our initial palette and styles may change as we iteratively develop the app, having a theme will allow us to do so easily from the top-down, as opposed to going back and changing the CSS in multiple places.
Currently, our custom theme has both a primary and secondary color (with light, main, and dark variations), a default font and text color, a default and secondary background color, an error color, as well as two different variations of body text.
Brian and I also put together some documtentation related to the types of MUI components we will likely want to use for our component, along with some basic instructions on how to utilize the theme attributes in our inline styling.
I also put together a ThemeExample component so our team can see what the various theme colors and fonts look like in the browser and how to use them in our code:
Results Observed
I've learned a ton about Material UI over the past few sessions, and I think having a theme in place and ready to use will make development more efficient and will allow each team member to focus on the important pieces of their components instead of having to worry too much about CSS and HTML during development.
0 Comments
0 Comments