This is a good junior level challenge to practice on. I challenged myself to knock this out in a day(8hrs). That didn't happen! I noticed that I end up having to go back to the markup to add complexity due to needs. My challenges start with me jumping straight into the IDE and that leads me to too many revisions. On the scale of complexity I feel pretty close to the bottom here and I can imagine the time saved will add up.
I want to work toward being able to develop something like this within a day. Going forward I'm going to practice pseudo coding to develop better structure from the beginning. I hope to better identify issues like, needing a container or best properties for the use case.
As always feedback is welcome! Thanks for checking this out.
Libraries.. WOW. ChartJS might not be the best example but it's easy to see why these are useful and frustrating at the same time. I felt like ChartJS is currently well supported and has been around long enough to have the best 1st time experience with. I understand libraries well enough that each one has it's own quirks based on the dev/dev team behind them. I ran with a CDN(seemed easiest) added the canvas element and went to the js. I figured an IIFE was a good use and fetched the JSON data and instantiated the chart class. Kinda curious what thoughts are about this method. Maybe not best practices but the chart was up.
On top of it being the first library I've use I also don't have a lot of experience in using objects but I felt like this was pretty straight forward. The nested options object became majority of the js being that formal decisions are made within the Chart instance. After scouring the docs I went back and forth and came out with something I feel good about. Most of the formal decisions are based on mobile first. This caused one problem that I know for sure and that is the overall height on the graph in desktop format. As much as I looked, I couldn't seem to manipulate it. In these projects I try not to get lost in details like this due to the time it could take figuring it out. That obviously would be different in a client-based project. I'll note it here and maybe get to fix it in the future.
Overall I would recommend ChartJS for this challenge.
This is the way to go for accessibly. My gripe here is that you're ending up declaring twice (HTML & CSS) your breakpoints. I'm guessing that in most cases there will be a few different breakpoints but it just seems like most format decisions are made in CSS and that changing the src url should be the standard. Tell me why that's not the case? To further emphasize this, adding complexity like a grid format may lend itself to additional use of the size attribute. When doing that it formally ends up being written just like a media query in CSS.
Blanket statement incoming: I've found that I keep building more and more complexity into these challenges and you have to keep going back on the things you've learned in the past to update them and find how they incorporate into the extra details your newly learned element has added. This is still messy(css) and I've broken down and rewrote it 3x already. Doing it over allowed me to rewrite where which class properties needed to go to work between the hamburger nav and mobile-first workflow.
The bigger picture here is finding how I can implement a more standard approach like BEM in my structure to help sort out the madness. I've kind of started with my class naming but need to take the deep dive to understand all the whys and edge cases where the standard is pushed.
APIs. First go at using one. I quickly came across the fetch() method and ran with it. Will continue to work on more complicated API data integration. Noticed that firefox might not fetch more than once and I'll need to figure that out.
Plan to revisit and use the JSON file to dynamically add the data. In the future I would like to get away from using a plugin to compile scss. Feel like the JS could be cleaner because the 3 forEach loops in there for something pretty simple.
I used scss for the first time trying to gain some experience and finding out it makes life a little easier for styling. I really like that in sass and scss you can nest styles. In my mind I can keep track of the elements easier while styling. Variables are a little cleaner as well. Mixins are going to be a time saver especially in larger projects that use set styling rules. Overall I will continue to use scss going forward simply for the cross browser support it adds. This project in particular isn't the best example. In order for me to copy the layout I had to fiddle with padding and margins in elements rather than just setting up flex boxes with values like space-around.
I found the JS a bit tricky at first. I saw that the examples most likely used block elements/event listeners to toggle classes like 'hidden'. At that time I thought it would be a better solution to inject some elements and have some css baked in to position them. I've seen it used in a tutorial in the past and it seemed like an easy way to add an element to be used for something like an error message. I should also mentioned that this tutorial briefly went over security risks with it. So when I ran into a bit of difficulty wanting to remove the injected HTML I went down a rabbit hole of ways to safely inject HTML. Turns out it's just a really not good idea and should be avoided altogether if possible. So I went back to original thought and this is the solution I developed.
Played a bit with pseudo elements and animations. Learned that pseudo elements are useful for adding things like SVGs but if you want to use eventlisteners to trigger them I could not find a way to target them. Just touched the tip of animations and what I did in the project is pretty much an example in MDN documentation. Understand that the transform property is going to be the thing that is played with the most for manipulating the object. Translate X&Y are how the movement is taking place. Keyframes help you break down the series of events. Should be fun to explore this more in depth.
Spent way longer on this then I should have. I knew the layout switch between web/mobile would lend itself using grid for layout so I took the opportunity to explore css grid. Found that when you've gained layout intuition from using flexbox, grid challenges that quite a bit. Containers are important and simpler concepts like aligning items are not like you'd expect. Still worth the exploration and definitely something I need to practice more. Scaling seems to be my biggest issue here. My guess is that I am not using the grid-template props in the best way. I've picked up that these two are often used with each other and I now am starting to break down layout with that perspective.
Few hurdles in this one (he hee heeee.........) Got stuck on the JS and remembered helper functions help break down the tasks and also make it easier to read. Picked up a few new attributes. Pretty good project.
I've been working on making these components as responsive as possible. This currently only has one break due to me wanting to try and keep it the fewest breaks and time. May revisit this in the future. Any feedback is welcome. Thanks
I'm trying to use less and less static values and make designs responsive as possible. SVGs are also new to me and I'm continually learning how to manipulate them. Any and all feedback welcome.
Did my best here. I feel like there are a lot of static values but at the same time it seems like these smaller component/cards lend themselves to it. Thoughts?
Spent way too long trying to get these sizes right. Trying to find the balance between accuracy and a good responsive layout. Learning one challenge at a time.
