Oh, the excitement of starting a new project and learning new tools!
Could this excitement makes you overlook the basics?
If you are a student assigned to a new team with a brand new project in your hands you’d know what I am talking about. That feeling you get when you open your project’s scaffolding, that skeleton framework that has predefined practices and standards you should be working with. You skim through the documentation to find the familiar and stop at the new tools to assess the complexity and level of interest.
What caught my attention?
Where do I start? I’ve never heard of Storybook or Ant Design tools before and they seemed very interesting. AntD, I couldn’t wait to start playing around with this React UI library. Storybook looked pretty cool too. I planned on searching for a tutorial to better understand it. Deploying to AWS didn’t call my name. Never done it but I wasn’t willing to dive in right away. Maybe someone else in the team might get excited about dealing with environmental variables and the like. I just wanted to get my hands on the code so I volunteered to work on the frontend.
Story Squad, when finished, is gonna be pretty cool. The stakeholder’s vision is to create a game where story tellers ages 8 to 12 get to get paired up with others to share original drawings and handwritten stories. The participants can give and receive real feedback from their peers. They read a story from a pdf document, follow a prompt to handwrite and draw their contribution, and upload the pages to the app. Then in a contest that lasts a week, winners are selected by the amount of points they earned. Children will have fun while improving their reading and writing skills.
What complicated things?
AntD has easy-to-use components and an easy to follow documentation with examples of code snippets on how to manipulate them. So far so good. Our project has a Figma file. This UX design document tells us exactly how the application should look to the T. Very cool ah?
I imported AntD components to build up the parents’ dashboard. Beside styling, I should add functionality to link Nav to other pages and to be able to add a new Child info to a backend’s endpoint by creating a form. Then display the children onto the parent’s dashboard by building a card component for each child.
It gave me so much joy to see how my pages were coming together in my local host. I had to tweak some of the css to have them look like the Figma specks. Wait, did I mention we’d have to use LESS CSS files for styling? When I first saw it, I said: “No problem. We got this.” It was among our familiar tools. We’ve learned LESS and CSS preprocessing and syntax about 6 months ago. For a week. We sure remember how to do it. My team agreed. Less was even cooler in this project because it’s used along Craco to take care of the React scripts so no extra compiler running on the side. And AntD loves Less, big documentation on theme overrides and variables.
Someone volunteered to build the backend API. Other team members worked on the login and registration pages. Just don’t ask them to tell you about Okta. They spent way too much time trying to figure out it’s widgets and documentation to later on realize they didn’t need the registration page for release one. Okta is an identity manager service that provides a centralized authentication for our app. Don’t get me wrong is pretty cool, after you learn how it works. Just changing the widget styles to mimic the mock page was proven rather difficult. Nonetheless, their Less files had great css styling to make those pages look awesome.
The moment of true came when we had our first merging party. My parents’ dashboard looked awesome and so did their login and child dashboard pages, at least in our local machines. After merging, their css styles got combined with mine and vice versa. We were scratching our heads because we all had an individual styling file for each component. If you know how Less works you can tell what’s wrong with this code:
Yep, If you’re thinking about the classes not being nested, you are right. On the above code, if a style didn’t have a specific class name, the styling would be shared among other files that used global classes like AntD components. Even though Less looks just like CSS, Less has different rules. The way it works is we write our code into a .less file, it’s then watched by a compiler that’s using javascript to convert it into CSS file that’s read by our HTML.
Nesting is an important rule in Less. We place our child styles inside our parents. Not only is it easier to parse, but it can be collapsed in our IDE for better manipulation. It also keeps our classes contained within our parent class.
Moral of the story. Refreshing your understanding of familiar tools is as important as learning a new one.
As for me and my team, we’ve got this! Our strength lies in team communication and strong collaboration standards so no matter what issues might come our way we will put our heads together and we’ll overcome it.
We will finish our project in the time projected. Phase one has been completed. We added Redux as a state management. We’ve built children and parent dashboards along with all components tied to them. Backend is completed and communicating with the frontend. A PDF reader has been added to the children’s components. The site is deployed. We learned that if you have one empty space at the end of one of your environment variables the deployed page will return blank.
I can’t wait to see what else I’ll learn on phase two of this project.
