kiprasmel / server-party

Come join the party! 🎉 https://server-party.kipras.org
1 stars 0 forks source link

v1.0 - overview & aftermath #1

Open kiprasmel opened 4 years ago

kiprasmel commented 4 years ago

The progress - tasks, issues & bugs etc. - will be tracked in the v1.0 roadmap.

The general overview, project planning, decision making & the aftermath will be discussed here.

Let's get the party started!

kiprasmel commented 4 years ago

For an overview, I'm thinking about the tech, implementations & stuff.

We'll use CRA with typescript for the client.

For styling, I'd go either with emotion or tailwind, and I think tailwind fits in better here + I'd like to experiment with it more, so that's that.

Since we need to support all modern browsers + IE11, we cannot use grid, but we won't need it anyway -- flexbox ftw. As per caniuse, the support is good, with a few bugs for IE11 - flex-basis requires a unit, and items are not correctly vertically aligned if used with min-height. Obviously, the space-evenly property support isn't good, but all of these concerns don't really bother us. So flexbox it is.

Note - see also https://tailwindcss.com/docs/browser-support/

For state management, I could use redux, but it seems a little overkill for this project. We'll be fine with react's context here.

For tests, we'll use react-testing-library + jest.

And I know we shouldn't use too many libraries, but I think that the automatic animations via react-flip-move would really improve the UX (think server sorting). We'll use it if I have extra time. Edit: Turns out almost all of the returned servers are different each time, and thus the animation turns out meh. Everything feels better without it, so I'm not going to use it!


As for the functionality itself:

The log-in is pretty self explanatory.

The sorting is a little more complex. I've already sketched it out & I like the UX. Basically, I want to have an array of "sorters", each having:

  1. a field by which it can sort;
  2. the order by which it sorts - either ascending or descending;
  3. the priority over other sorters;
  4. a toggle to enable/disable itself.

that should be pretty fun.

It would be useful to have the sorting configuration saved somewhere - probably context + localStorage (or on the backend, if I had control over it:D).


As for the deployment - the simplest solution would probably be github pages or netlify - we'll see.

kiprasmel commented 4 years ago

The Aftermath

Here we are. It's been a fun week:D

1. How did it go?

I feel like the project went pretty darn well! I enjoyed working on a new project again.

It was a good learning opportunity - there's been some tech I've been looking at for a while but haven't really used in a project yet, and here I did just that!

1.1 CSS, styling and tailwind

I've watched a few screencasts from the creator himself, Adam, using tailwind to build cool interfaces, but that was about it. Trying tailwind out now -- the experience was amazing! I've already been a fan of CSS-in-JS (namely, emotion), mainly because you don't have to come up with names for classes and hop between separate files to change something -- having the styles right there in front of you just made it easier to play, edit and have a clearer view with for me. But tailwind was on another level -- I didn't need to write css and instead was able to just use class names that I needed to get the desired styling.

This proved to be both faster and cleaner - instead of the usual approach or css-in-js, which can quickly lead to the element's styles taking up a lot of LOC / space and thus making the component's JSX too verbose & harder to work with, tailwind instead had classes which were both concise and intuitive. This made working with the layout, styling, responsiveness etc. a breeze! Would recommend.

Honorable mentions: postcss. Amongst other things, I used css custom properties (css variables), which are not supported in IE 11, but it was super easy to fix it - I just threw in a plugin to transform them at build time & went off with my day.

1.2 Testing

Not gonna lie - I wasn't very used to testing my frontend code:D

Make no mistake - I'm not completely new to testing. Previously, I've mostly been testing my utilities and things of such nature with unit tests. That's contributed to helping me understand the greatness of pure functions, avoiding side-effects and the joy of functional programming & it's principles in general (without taking it too far, obviously - i.e. monads are pretty cool, but perhaps not as easy for everyone to understand & maintain:D Programming's a team sport afterall).

But this was a little different. I've stumbled upon, surprise surprise, react-testing-library. It goes by the principle of "The more your tests resemble the way your software is used, the more confidence they can give you". This basically translates to testing the application as close to how a real user would be using it as possible, thus avoiding the implementation details, which means you can make a feature work however you want to -- what matters is if it works correctly or not:D

So, after struggling a bit and fixing some weird errors caused by not fully updated dependencies & a wrong jest environment, I went on and wrote some integration tests -- mostly for the different pages & components those pages used. It seems like they're working fine, but I'd welcome feedback in regards to the tests (and/or anything else, for that matter).

2. The issues I faced

2.1 Struggling with things I should've learned better first, or, RTFM

I jumped in and started attempting to write tests without really understanding how I'm supposed to do that and what's available to me, thus getting frustrated when things didn't go the way I wanted them to :D Rookie mistake - I should've read the docs more thouroughly in the first place. After "wasting" a bit of time, I realized this and did the right thing. Everything turned out okay.

3. What did I think about the project itself & the requirements?

I think that the requirements gave me the freedom to express my skills pretty much however I wanted to, and I liked that.

3.1 Design, responsiveness and building cars with(out) steering wheels

The part that there was no design comes to mind especially. I had fun coming up with some basic sketches and thinking about how things will look and feel like before coding, and that really helped. I was also able to develop mobile-first, and only later make everything responsive for bigger screens, which is indeed the way I like go about things if they need to be responsive.

Talking about responsiveness - there weren't requirements to make the app responsive, but I did it anyway. Same with the landing page, same with the 404 page. Basically, I was thinking something among the lines of "If you're going to build a car, the requirements might not state that it needs a steering wheel, but if you're somewhat experienced and know how a car works, you of course are going to add the steering wheel amongst other must-haves". And I think this was the right thing to do. But the lack of a statement from the requirements, I feel, leaves a gap for ambiguity. Perhaps worth considering; just my opinion though.

3.2 Internet explorer

The requirement to support IE 11 was a bit unusual to me - I haven't previously had to take something like this into much consideration. Though, I have long time been aware and have used things like caniuse.com to check up on browser support of various features etc., so I did just that and as mentioned in the overview, the only problem would've been css grid, so I just used flexbox instead. And then, in a single commit, I fixed everything else that was needed to make things work on IE 11. The docs were pretty good on this one, thus making it fairly straight forward.

Funny thing is - in order to test out and confirm it worked, I had to, for the first time in my life, unironically use internet explorer for something other than downloading chrome - now that was a new experience xD

3.3 CRA

I was wondering why create-react-app was considered fine for only entry to mid level positions. Perhaps you wanted to see if the developer is able to configure babel & webpack themselves? Because I myself just found it faster to use CRA and instead of spending time configuring stuff, I instead shipped more:D Obviously, it's most likely going to be useful to know how to configure the tools yourself, so I was just interested in your position on this.

3.4 http(s)

Also, small nitpick - the login url provided in the requirements is using http, but making a request with i.e. curl only works when you're using https. No biggie, just consider updating the url:D

4. The time I spent

The total time it took me to complete the tasks outlined in the v1.0 roadmap was about 30 hours.

I originally thought it'd take me around 20 or so, and I think I could've managed that. But as I progressed - I had a lot of fun, and decided that I want to really step up and make the project stand out. That's about it.

I would, however, absolutely love to become more productive at what I do.

5. Now what?

I appreciate you taking the time reading this and probably reviewing the project / code aswell -- thanks!

I've tried my best and I hope the results show it. The feedback, constructive criticism and all this good jaz would be really helpful - thanks in advance:)

And, well, I'm looking forward to the next stage.

Have a nice day ☀