Stories by Aaron Klaser on Medium

Testing Redux Sagas

Aaron Klaser — Fri, 10 Aug 2018 17:59:26 GMT

As much as want to take credit for this post this was mostly written by John Pipkin. It was real good and helped me a lot and I wanted it to be shared with the world.

Click here for his full article

So testing generators it’s best to think of them as loops that execute when you tell them to.

Step 1

it(‘should return 6’, () => {
 // we’ve set up the generator, but we haven’t called next yet so we’re not at a yield
 const gen = count()

expect(gen.next().value).toEqual(call(addNumber, number, 1))

expect(gen.next(1).value).toEqual(call(addNumber, number, 2))

expect(gen.next(3).value).toEqual(call(addNumber, number, 3))

expect(gen.next(6).value).toEqual(put(something(6)))
})

function *count() {
 -> // We haven’t told the generator to exicute anything yet so we’re not at a yield
 let number = 0

number = yield call(addNumber, number, 1)
 number = yield call(addNumber, number, 2) //3
 number = yield call(addNumber, number, 3) //6
 yield.put(something(number))
}

In this step we haven’t told the generator to do anything yet, so we don’t have anything to test.

Step 2

it(‘should return 6’, () => {
 const gen = count()

// This next is called, we’re seeing what the yield will be
 expect(gen.next().value).toEqual(call(addNumber, number, 1))

expect(gen.next(1).value).toEqual(call(addNumber, number,2))

expect(gen.next(3).value).toEqual(call(addNumber, number, 3))

expect(gen.next(6).value).toEqual(put(something(6)))
})

function *count() {
 let number = 0

// Generator is paused here, waiting. The yield call(addNumber, number, 1) hasn’t executed
 -> number = yield call(addNumber, number, 1)
 number = yield call(addNumber, number, 2) //3
 number = yield call(addNumber, number, 3) //6
 yield.put(something(number))
}

Here we’ve executed gen.next(). We’ve told the generator to go the yield statement and wait. So now we’re paused at the ->, but we haven’t actually ran the code.

When we get gen.next().value here we’re just getting what the yield WILL do.

Step 3

it(‘should return 6’, () => {
 const gen = count()

expect(gen.next().value).toEqual(call(addNumber, number, 1))

// called next here, this evaluated the previous line. We pass in the return value from the last line
 expect(gen.next(1).value).toEqual(call(addNumber, number, 2))

expect(gen.next(3).value).toEqual(call(addNumber, number, 3))

expect(gen.next(6).value).toEqual(put(something(6)))
})

function *count() {
 let number = 0

number = yield call(addNumber, number, 1)
 // We evaluated the previous line, now were waiting at the this yield
 -> number = yield call(addNumber, number, 2) 
 number = yield call(addNumber, number, 3) //6
 yield.put(something(number))
}

Here we’ve called gen.next() again. The generator sees that command and executes the yield that it was paused at and continues the next `yield` statement. It will pause here ->. gen.next() tells the yield statement it was at to execute, we can pass what we want returned from that into the call
We were paused at yield call(addNumber, number, 1), we wanted that to return 1 so we pass that in when we actually execute that line.

Step 4

it(‘should return 6’, () => {
 const gen = count()

expect(gen.next().value).toEqual(call(addNumber, number,1))

expect(gen.next(1).value).toEqual(call(addNumber, number, 2))

// Called next again, we evaluated the call to (number, 2) and specifiy its return value in this next
 expect(gen.next(3).value).toEqual(call(addNumber, number, 3))

expect(gen.next(6).value).toEqual(put(something(6)))
})

function *count() {
 let number = 0

number = yield call(addNumber, number, 1)
 number = yield call(addNumber, number, 2) //3
 -> number = yield call(addNumber, number,3) //6
 yield.put(something(number))
}

This one is just like the previous step, just to illustrate what I’m talking about. The yield to call(addNumber, number, 2) should return 3 so we pass that in to the call to gen.next(3) because we’ve told the generator to execute that line and we want it to return 3.

Step 5

it(‘should return 6’, () => {
 const gen = count()

expect(gen.next().value).toEqual(call(addNumber, number, 1))

expect(gen.next(1).value).toEqual(call(addNumber, number, 2))

expect(gen.next(3).value).toEqual(call(addNumber, number, 3))

// Called next again, we evaluated the call to (number, 3) and specifiy its return value in this next.
 // I’ve intentionally returned the wrong value from the call to (addNumber, number, 3) to illustrate how the return in next works
 expect(gen.next(8).value).toEqual(put(something(8)))
})

function *count() {
 let number = 0

number = yield call(addNumber, number, 1)
 number = yield call(addNumber, number, 2) //3
 number = yield call(addNumber, number, 3) //6
 -> yield.put(something(number))
}

We’ve called gen.next() again so now we’re waiting at the yield to put. In this example you can see I intentionally returned the wrong value `8` in gen.next(). This is to illustrate that next takes in the return value of the previous execution. Essentailly mock data in this case. Now we see that the yield we’re paused at is the put(number). Since number in this case is 8 (because that’s what we told call(addNumber, number, 3) to return, that’s what we’re looking for.

Step 6

it(‘should return 6’, () => {
 const gen = count()

expect(gen.next().value).toEqual(call(addNumber, number, 1))

expect(gen.next(1).value).toEqual(call(addNumber, number, 2))

expect(gen.next(3).value).toEqual(call(addNumber, number, 3))

expect(gen.next(8).value).toEqual(put(something(8)))

// Finally call next again to see there are no more yields
 expect(gen.next().done).toBeTruthy()
})

function *count() {
 let number = 0

number = yield call(addNumber, number, 1)
 number = yield call(addNumber, number, 2) //3
 number = yield call(addNumber, number, 3) //6
 yield.put(something(number))
 ->
}

Finally, we call gen.next() again. Since there are no more yields to wait for we can see the saga is done.

Testing Redux Sagas was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hacked Tabletop TV Beta

Aaron Klaser — Sat, 07 Apr 2018 15:38:29 GMT

Streaming Board Gaming Live on Twitch

After many months and well over $4000 spent on gear and countless hours of trial and error, we are excited to premier the Hacked Tabletop TV on Twitch.

It’s going to be a glorious epic train wreck, the likes of which you will not want to miss.

The whole reason I started streaming on Twitch was to learn the ropes, build up a small following, get all the gear figured out, all for Hacked Tabletop TV. It’s has been not simple task, and way more of a time commitment then I expected. I wrote and article about it a few weeks ago. And let’s be clear, I am still no expert and still have a lot of work to get things set up how I want, but I think we are ready to start Hacker Tabletop TV!

What is Hacked Tabletop TV?

Honestly, we don’t know where this is gonna go, but we know where it will start.

Hacked Tabletop TV will be a weekly show where we talk about board games, reviews, opinions, jokes (often ruthlessly attacking each others intelligence), but most importantly, we are play board games… LIVE!

I know what you thinking

We have all seen the countless number of videos of people place board game on camera. Crappy camera, crappy lighting, and crappy sound. We plan to be different, maybe a little rough at first, but quality has always been my top priority which is part of the reason why it has taking this long to get started.

We will have soft box lights, an overhead DSLR camera so you can get the best view of the board, plus two webcams grabbing different angles of us, as we play. I have an Elgato Stream Deck that will allow me to change cameras on the fly, and trigger sound effects and animation pop-ups.

All this semi-professional stream quality is on top of the fact that we’re moderately entertaining people that love to joke and pick on each other and have a passion for all things gaming, both tabletop and digital.

Note: Some jokes and most language might be inappropriate and not suited for younger viewers.

When and Where can you watch Hacked Tabletop TV?

Thursday night at 7:30 on Twitch at https://www.twitch.tv/loserkidklazy

During these first few attempts, we will be streaming on my Twitch channel. We will eventually branch out to multiple networks to find what works best for our views. I like the idea of Mixer because it’s real-time and we can play games with our viewers but for now, Twitch will work.

What are we playing?

This first week we are playing our new favorite game, Dinosaur Island. You can see our review here.

Other upcoming games include Gloomhaven, Spirit Island, Azul, Sagrada, and the Gaia Project.

If you have any game suggestions, or maybe you want us to play your game, feel free to reach out to us at hackedtabletop@gmail.com, or you can message us on facebook.

How can you help?

Come hangout, create an account if you don’t already have one, Follow LoserKidKlazy, and chat with us live. We will all have our phones on and be available in chat. As an added bonus, you will gain “cool points” while you are watching us play games.

Hacked Tabletop TV Beta was originally published in Hacked Tabletop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ultimate Audio Streaming Setup

Aaron Klaser — Thu, 15 Mar 2018 20:06:08 GMT

Twitch Streaming for Xbox and PC

Remove Spotify, include Xbox Party Chat, and use wireless PC headphones on Xbox One

I have been streaming on twitch for a few night and I have ran onto and handful off issue when it comes to have auto like Spotify play in the background especially when I do my code streams on Wednesday night, because I want to record the videos to edit them later, but things like Spotify make cleanly editing impossible.

The other MAJOR issues is when a stream my Xbox, I need to be connected to both for audio and chat, so I can talk on Discord or Xbox Live, and hear my computer and my Xbox audio.

After many hour of research I came up with a pretty okay solution with our needing to buy an expensive mixer device and it lets me us my Yeti mic for Xbox Chat.

Whats You need

Hardware

PC with Windows 10 (Alienware R7)
Xbox One
Microphone (ex. Blue Yeti)
Elgato HD60(S)
Wireless Headphones (Arctis 7)

Software

OBS (or SLOBS)
Voicemeeter Banana
Virtual Audio Cable (With the Extra Cables A & B — $5)
Audio Router
Spotify
Discord
Windows 10 Xbox App

The Diagram

How To Set It All Up

Step 1: Download and in all Install all the application
OBS
Voicemeeter Banana
Virtual Audio Cable (With the Extra Cables A & B — $5)
Audio Router
Spotify
Discord

Step 2: Set up Spotify, Discord, and OBS. This one you can handle on your own.

Step 3: Install all three Virtual Cable Drivers. Then, restart you computer so all 3 driver will work. If you open your playback devices (right click on volume and click playback) You should see, rather counter intuitively, Playback now has three CABLE Inputs and Recording has three CABLE Outputs.

Step 4: Set CABLE Input (Not A or B) to be the default playback device for BOTH Default Device and Default Communications Device. Right click on CALBE Input and make check Set as Default Device and Set as Default Communications Device. If the are both set there will be no options under Disable.

Step 5: Install (well… run) Audio Router. Find Spotify in your list, it will need audio to show up in the mix, or you click File > Switch View and select it from the list. Then choose Route… and pick CABLE-A Input

Note: This app is in crazy alpha mode and for some reason does have yet so for now you have to do this step every time open Audio Router.

Step 6: Open Voicemeeter Banana and set the follow mappings then save so you can load again later.
Hardware Input 1 => CABLE Output
Hardware Input 1 => CABLE-A Output
Hardware Input 1 => Line (Elgato Sound Capture) or CABLE-B Output if your not stream a console.
Hardware Out => Set A1 to Headphones (Arctis 7)

IMPORTANT: Make sure each A1 on each input is select otherwise the sound wont go to your headphones on the A1 output.
EVEN MORE IMPORTANT: After making any changes to the Voicemeeter Banana or Audio Router, you almost always have to restart the audio engine in Voicemeeter Banana by clicking Menu > Restart Audio Engine

Step 7: Open your OBS scene:
Add new Video Capture Device name it Elgato and select Device as Game Capture HD60 S
Add new Audio Input Capture name it mic and select Device as Microphone (Blue Yeti)
Add new Audio Output Capture name it spotify and select Device as CABLE-A Input

Then, click the gear the on Spotify mixer > Advance Audio Properties. For Spotify over under Tracks uncheck all but #1

Step 8 (Option for Party Chat): Use the Windows Xbox App to join Party Chat on your PC, Not on the Xbox. It works exactly the same way.

There you go. Now you can stream live with background music but not have it include in your recording so you can edit. This is also copyright friendly :)

What you can’t do

Talk in the general online chat on Xbox Live games like Call of Duty. But to be honest, no one wants to hear you talk especially if your voicing your inner monologue on Twitch. If people wanted to talk you, you can use Party Chat on the Xbox App, then your views can hear them and your not annoying the crap out of people too stupid to mute you in-game.

Video Explanation

IMPORTANT NOTE: I meant to record this but accidentally Streamed it so you can hear audio that you shouldn’t hear but I promise it works. I will make a follow-up video with every running live in the next week!

Don’t forget to follow and watch me live at https://www.twitch.tv/loserkidklazy

https://medium.com/media/7e2691c6003e0d0b129c1d4fa0d85469/href

Ultimate Audio Streaming Setup was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

What I Have Learned After 2 Weeks of Streaming on Twitch

Aaron Klaser — Fri, 09 Mar 2018 19:13:33 GMT

For the last ten years, I have spent all my free time trying to start my own companies or build something new and innovative. But for the has few months I have shifted my focus to giving back and trying to create a brand and reputation for myself in the JavaScript community. It started with Medium, and then a board game review blog and the most recently, live streaming on Twitch.

Shameless Plug
Wednesday nights (9:30cst) I stream javascript programming. If you want to learn some code tricks while being slight entertained follow me, I could use the followers. LoserKidKlazy
Sunday through Tuesday I stream games like the Witcher 3 and My Time at Portia. The rest of the week I will hop on an off randomly if I have the time.

Heres what I have learned after 2 weeks of streaming.

First and most important

Your significant other will not be happy with this. They might try to play it cool, but for some reason as soon as you turn on the camera they want your attention, and then they are mad at you for days about it. Just know this before you start, and to my wife, if you are reading this, I’m sorry, and I love you :P

It’s a lot of work

It’s far more work than I actually expected. Learning how to use the Gear, getting everything setup, building a brand, researching how other people do things, figuring out what tools to use and how they work. It’s a lot of effort to and research, and trial and error. Yes, you could just start broadcasting yourself playing games but if you’re want to be even mildly successfully expect to devote a lot of time to getting started.

It’s expensive

This is no joke. Sure you could stream on a mediocre PC, but it’s not going to be very good. I was going to use my Mac Book Pro at first and an Elgato HD60s to stream my Xbox, but my Mac wasn’t strong enough. So I had to buy a PC, and a better webcam, and desk, and gaming headset, and keyboard, and a mouse, and a monitor… you get the point. Some of you might have a lot these things laying around, but they do need to be good if you want to look professional. I’ll list my gear and costs to date below.

It takes awhile to get going

Like I stated up above, there is a lot more to it than just turning on your computer and streaming. The learning curve is a little on the steep side at first. I have been trying to start streaming for about 2 months, but it’s taken about 6 weeks to get everything set up in a way they I can stream with any form of consistency.

Scheduling and consistency is important

Everyone will tell you this, and it makes sense. You need to be consistent, and a have a schedule and try to stick with it. You want your follower to know when they can watch you, and maybe even some will be excited and looking forward. Don’t let them down.

Its weird, but important, to talk to yourself

I’m still getting used to this. Most of the time you won’t have anyone in your room, and even when you do most people still won’t be talking to you. It’s not a live chat; you are streaming to produces entertainment, be entertaining. In fact, Twitch has a 10-second delay so round trip you could be off by 20 seconds. You have 15 seconds to impress a lurker. You need to be exciting to watch even when no one is watching unless you’re are insanely good at a particular game, and even then.

If you are going to code be sure to zoom in

My first code stream was terrible, you can see it on my youtube page, or better put, you can’t because my 1440p monitor streamed at 720p was so tiny you can barely make out what I’m coding.

Pay attention to your audio

My first code stream I also forgot to turn my audio on for the first 8 minutes. Oops. And if you have your Twitch stream up for chat or something, be sure to mute it because it will for some weird feedback loop.

Don’t stream games that are too popular, or not popular enough

If it’s a popular game, all the big guys are going to have all the viewers. If it’s not popular enough, no one is ever going to find you. You can use a site like Twitch Strike to see that you should be playing. Then find something YOU WANT to play.

Build your brand

There are few ways to do this. You can buy something if you are less artistically inclined, or you can build your own. I’m working on building my own brand right now, and again this adds to even more time spent on setup and research.

You can’t make money unless you get followers

Once you have 50 followers and meet a few other simple goals, you can become a Twitch Affiliate, which lets you get subscribers, which they pay $5 a month to support you and you get some kind of cut of that $5. This can add up pretty quick. Some of these big times followers make upwards of 100s of thousands of dollars a month. Granted they have been doing for YEARS. I don’t get, but It’s a thing. There is a Twitch Partner level as well. Not sure what the difference is, I just know I’m lightyears away from it.

Set a Discord Server

Everyone uses it’s for live chatting and offline chat rooms. It’s like Slack but better and more confusing.

Good Camera and Good Lighting

Light makes a HUGE difference, especially if you want to do a green screen. Get yourself two softboxs off amazon and set them up kind of in front of you and to the left and right of your desk. I had to use a boom arm to get mine in for of me on the right side because my desk is in the corner of my room. If you have a green screen be sure to set up a hair light to cast light on the back of your head, this will reduce the green screen bleed around your image.

Streamlabs and Chat Bots

I’m still trying to figure our the Chatbot, but using Streamlabs and Chat Bots is how you get some interactivity with your stream. If you want to have a pop-up and some audio every time someone follows you, this is how you do it. But, expect to spend a few days playing with it to figure out how it works and what works for your brand.

That’s about it for now. I am by no means an expert, but these are just a few of the thing I have learned over the last few weeks. If you’re interested in getting started, I hope this helps, and I wish you the best of luck. If you want to help support me, you can follow me on Twitch, Facebook, and Twitter at these links:

Twitch — https://www.twitch.tv/loserkidklazy
Facebook — https://www.facebook.com/LoserKidKlazy/
Twitter — https://twitter.com/awklaser
YouTube — https://www.youtube.com/channel/UCLND4ARfpDGvLpeS9T8LeXg?view_as=subscriber

As promised my gear list.

This is just what I have purchased in the last two months for doing this.

PC — Alienware Aurora R7 = $2000
CPU — Intel i7 8700
GPU — Geforce GTX 1080
RAM — HyperX Fury 16GB
Monitor — Dell 27" 1440p 144hz Gsync = $430
Capture — El Gato HD60 = $130
Webcam — Logitech C922 = $99
Mic — Red Yeti Mic = $160
Headset — Steelseries Arctics 7 = $150
Keyboard — Ducky Shine 6 — $150
Mouse — Logitech G602 — $40
Controller — Xbox Pro Controller / PS4

Desk — IKEA concoction = $270
Softbox Lighting and Green Screen = $150
Adobe CC — $30/month
Games — $100/month

Grand Total = ~$3,839

People Are Dumb and Should be Treated Like Morons

Aaron Klaser — Tue, 06 Mar 2018 17:51:57 GMT

A Guide to Good User Experience Design

In my ten years of web development and web design, I see people make the same stupid mistakes over and over when it comes to designing websites. Most people think that just because they understand something, that everyone understands it same way they do. But this never the case. EVER!

Important:
Someone, somewhere, is not going to understand something the same way as you understand it, no matter how simple or intuitive something may seem to you, it will not make sense to someone else, and there is nothing any of us can do about it. You have to accept this, understand it, and move on knowing this.

I want you to read that again. It is critical that you understand what I just said to be successful in pretty much anything you do, but most importantly design and user experience. These people are the lowest common denominator. Which means, just like adding fractions we need to break it down before we add it all together.

I have lived by one simple rule, and it as made be very successful as a web developer, a designer, and pretty much everything else I’ve done.

“People are dumb and should be treated like morons”

If you don’t want a user to think something, you better clarify, because someone is going to think it. If you don’t want a user to click something, you better hide it or disable, because some moron is going to click it no matter what it says it does.

Keep it simple, keep it stupid!

Just because something makes sense to you doesn’t mean it makes sense to everyone else, and it is better to error on the side of over clarification than leaving important gaps because you assumed everyone understood something.

Think about, for instance, reading the rules to a board game, and they tell you that you can spend the red tokens as health. But, as you look at everything in the game you realize that there a 3 different red tokens and the rules never clarify which red tokens to use. It’s probably the ones with the cross on it, but who knows! I didn’t create the game.

This kind of crap happens all the time, everywhere! And if people would just get out of their own heads for a minute, stop making assumptions based on logic we could solve a lot of problems. Most people, even the smart ones can lack the ability to think logically, if not all the times, then at least sometimes.

It is our jobs as developers and user experience designers to try to make things so simple, so intuitive, that anyone, of any age, of any intelligence can figure it out. Just ask yourself, would my Grandma understand this. And still even then.

I have worked with a lot of people over the years that struggle with this concept, and the crappy part is, these are usually the people that don’t think the same way as everyone else. I often refer to this as the Curse of Intelligence, when someone is so smart they are stubborn and overly logical to a fault. Anyone that has worked in IT for over a year knows who I’m talking about, and if you don’t there is a good chance it’s you, case and point, so keep reading.

“When I think of design and creating great user experiences, I generally think of it in terms of three things: usability, utility and desirability.” — Jon Wiley, Google

10 User Interface Design Guidelines

Visibility of system status.

Users should always be informed of system operations with easy to understand and highly visible status displayed on the screen within a reasonable amount of time.

Example: If a page, or a section on a page, is loading data, show the user a loading icon. Don’t wait for your page to load before taking the user to that page. This creates delays and makes the user feel like the site is broken. People are impatient and need instant feedback.

Match between system and the real world.

Designers should endeavor to mirror the language and concepts users would find in the real world based on who their target users are. Presenting information in logical order and piggybacking on user’s expectations derived from their real-world experiences will reduce cognitive strain and make systems easier to use.

Example: You wouldn’t make your user fill out his credit card information before shopping on your online store. You also probably aren’t going to make their cart their default homepage. Because thats not how people shop. You go to a store, look at products, fill your cart, then check out. Your users experiences should mirror that.

User control and freedom.

Offer users a digital space where backward steps are possible, including undoing and redoing previous actions.

Example: My god, we have all used these sites before. You get halfway through filling out some forms and you realize you $#@!ed up. To bad, can go back, got to start all over. Yeah… Don’t do that.

Consistency and standards.

Interface designers should ensure that both the graphic elements and terminology are maintained across similar platforms. For example, an icon that represents one category or concept should not represent a different concept when used on a different screen.

Example: Holy crap, this is probably the most abused rule. Learn More, Read More, Read, View More, View, More… PICK ONE!!! They are all the same thing really! Close, Cancel, Finished, Done, X… Yes, sometimes it makes sense to have different ones like and Close and Cancel. Just stay consistent with how you use Close and Cancel. And, if close is a red button with an X one page it better not be a green button with check on another page.

Error prevention.

Whenever possible, design systems so that potential errors are kept to a minimum. Users do not like being called upon to detect and remedy problems, which may on occasion be beyond their level of expertise. Eliminating or flagging actions that may result in errors are two possible means of achieving error prevention.

Example: Try not to show users errors unless there is a way that the user can fix it, and make that way clear and simple. If your user is filling out a form, and certain data is requires or must be in a specific format, don’t let them submit the form without first filling out that data. If your user doesn’t have access to a certain page or action, hide it so they don’t receive an error when they click on it or try to visit that page.

Recognition rather than recall.

Minimize cognitive load by maintaining task-relevant information within the display while users explore the interface. Human attention is limited and we are only capable of maintaining around five items in our short-term memory at one time. Due to the limitations of short-term memory, designers should ensure users can simply employ recognition instead of recalling information across parts of the dialogue. Recognizing something is always easier than recall because recognition involves perceiving cues that help us reach into our vast memory and allowing relevant information to surface. For example, we often find the format of multiple choice questions easier than short answer questions on a test because it only requires us to recognize the answer rather than recall it from our memory.

Example: Say you want to have a short survey after users checkout from your online store, while be it annoying no one is ever actually going to fill it out. Instead of requiring your users to describe their experience in text box, present them with multiple choices like; Great, Good, Poopy, Horrific, and then give them the option to express why they felt that way, even though they will never fill it out. Also helpful, if your survey has multiple pages, and you want to reference something from a previous question, include some blurb about that question and their answer on that page the user is currently on. That way the user knows what you’re asking them… even though that are never going to fill it out (-_-)

Flexibility and efficiency of use.

With increased use comes the demand for less interactions that allow faster navigation. This can be achieved by using abbreviations, function keys, hidden commands and macro facilities. Users should be able to customize or tailor the interface to suit their needs so that frequent actions can be achieved through more convenient means.

Example: Medium has a great example of hidden commands. If you are writing an article in Medium and you press [Command]+[ / ] it will open the Keyboard Shortcuts menu on in your browser. Its not customizable a but it’s really easy to get to and find a helpful shortcut key.

Aesthetic and minimalist design.

Keep clutter to a minimum. All unnecessary information competes for the user’s limited attentional resources, which could inhibit user’s memory retrieval of relevant information. Therefore, the display must be reduced to only the necessary components for the current tasks, whilst providing clearly visible and unambiguous means of navigating to other content.

Example: Cut the annoying intrusive ads that are littered all over your web pages. I know, that’s how you make money but mother of god, does anyone actually click on those things on purpose. Medium is another great example of clean minimal user interface. Nothing to distract the users from the stories being told. Sometimes less is more.

Help users recognize, diagnose and recover from errors.

Designers should assume users are unable to understand technical terminology, therefore, error messages should almost always be expressed in plain language to ensure nothing gets lost in translation.

Example: I have already hit on this point but the bigger take away here is to speak in plain english — or what ever native language your site is in. An error shouldn’t read something like “Our servers were unable to authenticate your identity token”, it should just be “Login Failed”… because, that’s what it is. Keep it simple, keep it stupid. Remember, people are dumb, even if your site is something like technical documentation for debugging a supercomputer and the only people ever to read it are computer scientists. Don’t assume they know what you’re talking about, because like I said before, someone won’t understand.

Help and documentation.

Ideally, we want users to navigate the system without having to resort to documentation. However, depending on the type of solution, documentation may be necessary. When users require help, ensure it is easily located, specific to the task at hand and worded in a way that will guide them through the necessary steps towards a solution to the issue they are facing.

Example: Sometimes shits complicated, and in those instances we might need to help the user. If you can, give them a tooltip pop-up. If it needs more explanation then a tooltip can provide, then create some sort of documentation page. But above all make both tips and/or the documentation follow all of the above rules.

Final Thought

A users experience shouldn’t be like an episode of Lost where the user is left with more $#@!ing questions and no $#@!ing answers.

Assume people have no clue what you are talking about no matter how obvious something actually is.

Remember to think to yourself, will my grandma understand this.

Source

People Are Dumb and Should be Treated Like Morons was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Replacing Redux Thunks with Redux Sagas

Aaron Klaser — Tue, 27 Feb 2018 20:31:57 GMT

The React Blog Series: Part Five

This article is part five in a weekly series on building a blog with React and is an extension of the code created in previous parts.

The React Blog Series

Part One: Building a website with React and Bulma
Part Two: Building a Blog with React and Contentful
Part Three: Import your Medium Feed into React
Part Four: Adding a Redux to a React Blog
Part Five: Replacing Redux Thunks with Redux Sagas
Part Six: (In Progress) Writing Unit Test for a React Blog with Redux Sagas

First of all, let me start with I am by no means an expert on this subject. I have only actually been using Sagas for the last two weeks. If you’re anything like me, as you read this, you will constantly be asking yourself, why the hell would anyone want to use this, it’s massive overkill, and you would be absolutely correct. It is overkill… for what I’m doing, but at the end of the day Sagas are better, more scalable, and infinitely easier to unit test which we will see in Part Six. If you don’t like my explanations or examples, I understand. There is also SO MUCH more to Sagas than what I’m going to use here. Here is the link to the Redux Saga documentation. Good Luck! — Aaron Klaser

What is Redux Saga?

Sagas are a redux middleware that handles asynchronous actions triggered in your application often referred to as ‘side effects’. They are constantly watching for certain actions to be dispatched, before they but in and take over controller of the situation.

Sagas are implemented as Generator functions that yield objects to the redux-saga middleware.

Wait, what is a Generator function?

!@#$ing magic, thats what!

But, heres a better explanation which I stole from Mozilla.

Generators are functions which can be exited and later re-entered. Their context (variable bindings) will be saved across re-entrances.

Calling a generator function does not execute its body immediately; an iterator object for the function is returned instead. When the iterator’s next() method is called, the generator function's body is executed until the first yield expression, which specifies the value to be returned from the iterator or, with yield*, delegates to another generator function. The next() method returns an object with a value property containing the yielded value and a done property which indicates whether the generator has yielded its last value as a boolean. Calling the next() method with an argument will resume the generator function execution, replacing the yield expression where execution was paused with the argument from next().

A return statement in a generator, when executed, will make the generator done. If a value is returned, it will be passed back as the value. A generator which has returned will not yield any more values.

Okay, Back to Sagas

Now where was I? Ah yes… Sagas are implemented as Generator functions that yield objects to the redux-saga middleware. The yielded objects are a kind of instruction to be interpreted by the middleware. When a Promise is yielded to the middleware, the middleware will suspend the Saga until the Promise completes. Once the Promise is resolved, the middleware will resume the Saga, executing code until the next yield.

Redux Saga middleware does a lot of the Generator magic for us behind the scenes yielding to saga functions like put, all, call, and takeLatest.

What happens is that the middleware examines the type of each yielded Effect then decides how to fulfill that Effect. If the Effect type is a PUT then it will dispatch an action to the Store. If the Effect is a CALLthen it'll call the given function. This separation between Effect creation and Effect execution makes it possible to test our Generator in a surprisingly easy way using next()

In short, Generators are pause able functions like a music track, and
Sagas are the DJ that press the pause play and stop buttons on the track.

But enough chit chat, let’s get started!

Install Saga

npm install redux-saga

Then in store/index.js let’s connect Saga. Saga is a redux middleware so we will be injected it into our redux applyMuiddleware function, but we will have to create it first.

import { createStore, applyMiddleware } from 'redux'
import { rootReducer } from './rootReducer'
import reduxImmutableStateInvariant from 'redux-immutable-state-invariant'
import thunk from 'redux-thunk'
import { composeWithDevTools } from 'redux-devtools-extension';
import createSagaMiddleware from 'redux-saga'

const sagaMiddleware = createSagaMiddleware()

export function configureStore() {
  return createStore(
    rootReducer,
    composeWithDevTools(
      applyMiddleware(
        sagaMiddleware,
        thunk,
        reduxImmutableStateInvariant()
      )
    )
  )
}

As of right now, this does nothing. We will need to initialize the sagas which need some set up before we can do that. We are going to basically gut our current thunk setups.

Creating Our Saga Helpers

We are going to use three helpers:

createAsyncTypes helper, which will generate a type object with pending, success, and error.
createActions helper, which will generate our actions for us.
createReducer helper which we will use to replace our switch statements.

In the store folder create a file called Utilities.js

///////////////////
// ActionHelpers //
///////////////////
const asyncTypes = {
  PENDING: 'PENDING',
  SUCCESS: 'SUCCESS',
  ERROR: 'ERROR'
}

export const createAsyncTypes = typeString =>
  Object.values(asyncTypes).reduce((acc, curr) => {
    acc[curr] = `${typeString}_${curr}`
    return acc
  }, {})

export const createAction = 
  (type, payload = {}) => 
    ({ type, ...payload })

///////////////////
// createReducer //
///////////////////
export const createReducer = 
  (initialState, handlers) =>
    (state = initialState, action) =>
      handlers.hasOwnProperty(action.type)
      ? handlers[action.type](state, action)
      : state

I might revisit these in the future, I’m not 100% sold on the createReducers approach yet, but for now it works and it’s pretty clean

Moving from Thunks to Sagas

Update Blog Types

Open store/blog/types.js

Before, we only had 2 types, we used BLOG_LOADING to set the loading state for both complete and error, and LOAD_BLOG_SUCCESS to load our data on success.

--- BEFORE ---

/**
* Blog Types
*/
export const BLOG_LOADING = 'BLOG_LOADING'
export const LOAD_BLOG_SUCCESS = 'LOAD_BLOG_SUCCESS'

But now, we are going to call our new help to createAsyncTypes which will create our three types automatically; Pending (loading ), Success (load data), Error (loading complete).

--- After ---

/**
* Blog Types
*/
import { createAsyncTypes } from './../Utilities'

//Using ASYNC as a convention to know that I'll have three types.
export const GET_BLOG_ASYNC = createAsyncTypes('GET_BLOG')

This will make more sence in a moment.

Update Blog Reducer

Open store\blog\reducer.js

This can be done one of two ways, we could just simply update the types in the switch cases to use the new type names we just created like this.

switch (action.type) {
  case types.GET_BLOG_ASYNC.PENDING:
    return {
      ...state,
      loading: true
    }
  case types.GET_BLOG_ASYNC.SUCCESS:
    return {
      ...state,
      posts: action.posts,
      loading: false
    }
  case types.GET_BLOG_ASYNC.ERROR:
    return {
      ...state,
      loading: false
    }
  default:
    return state
}

This is an example of what our createAsyncTypes types helper has done. It generated a type object with 3 values and using the convention _ASYNC we know that GET_BLOG_ASYNC will contains PENDING, SUCCESS, and ERROR.

Let’s make this a little bit more intelligent by using out createReducer helper and passing it an object instead of a switch statement.

Delete everything and paste in this

/**
* Blog Reducer
*/
import initialState from './../initialState'
import { createReducer } from './../Utilities'
import * as types from './types'

export default createReducer(initialState.blog, {
  [types.GET_BLOG_ASYNC.PENDING](state) {
    return {
      ...state,
      loading: true
    }
  },
  [types.GET_BLOG_ASYNC.SUCCESS](state, action) {
    return {
      ...state,
      posts: action.posts,
      loading: false
    }
  },
  [types.GET_BLOG_ASYNC.ERROR](state) {
    return {
      ...state,
      loading: false
    }
  }
})

Yes, I know what your thinking and I agree. This does look more confusing then a switch statement and just as clean. It actually took me a minute to understand what that object was actually doing because it wasn’t something I had ever written out like this we before. It’s creating an object that each equals and an anonymous functions but it’s setting the keys using square brackets.

obj = {
  key: fn,
  [key]fn
}

Or you can use arrow functions which you will need to a colon arrow and parentheses around the object.

export default createReducer(initialState.blog, {
  [types.GET_BLOG_ASYNC.PENDING]:(state) => ({
    ...state,
    loading: true
  }),
  [types.GET_BLOG_ASYNC.SUCCESS]:(state, action) => ({
    ...state,
    posts: action.posts,
    loading: false
  }),
  [types.GET_BLOG_ASYNC.ERROR]:(state) => ({
    ...state,
    loading: false
  })
})

Which ever way you choice is fine, let I said I’m not 100% on board yet, but I think this can help create an async reducer creator in the future ;)

Create Our First Saga

In our store\blog folder create a file called sagas.js

/**
* Blog Sagas
*/
import * as contentful from 'contentful'
import { all, call, put, takeLatest } from 'redux-saga/effects'
import { actions } from './../Blog'
import * as types from './types'

const client = contentful.createClient({
  space: 'qu10m4oq2u62',
  accessToken: 'f4a9f68de290d53552b107eb503f3a073bc4c632f5bdd50efacc61498a0c592a'
})

const fetchPosts = () => client.getEntries()

function* getBlogPosts() {
  try {
    const posts = yield call(fetchPosts)
    yield put(actions.success(posts.items))
  } catch (e) {
    console.log(e)
    yield put(actions.error(e))
  }
}

export default function* () {
  yield all([
    takeLatest(types.GET_BLOG_ASYNC.PENDING, getBlogposts)
  ])
}

So, what is this doing? Well, let’s start with the obvious.

client is my connection to my Contentful

fetchPosts calls our to Contentful to retrieve my posts and returns them as a Promise

getBlogPosts is our actual saga. It first yields the call to fetchPosts, saga magic kicks in and pauses the function and waits for Contentful to return the data. Then, once the data has been successfully returned, instead of returning a promise it actually return the data to const posts and calls next() behind the scenes which tells the function to play again. It then calls yield put which magically dispatches the the actions with the post items. If fetchPosts() where to fail, an exception is thrown which triggers the catch.

export default function* is the action watcher that is connected to the Redux Saga middleware. This is similar to trigger the actions, except instead of the call an action and the action being dispatched to the reducer, the saga watches for that actions to be called, then it intercepts and calls the saga. takeLatest tells Redux Saga to stop any previous running saga task if still running then run a new one.

takeLatest(types.GET_BLOG_ASYNC.PENDING, getBlogPosts) says when the action types.GET_BLOG_ASYNC.PENDING is called, stop any getBlogPosts tasks previously call that my be not be completed and call a new getBlogPosts() function.

The yield all function is a kind of housing to hold all of our watchers for the blog sagas. If we have more actions, we could create more sagas and create more watchers to call those sagas, those additional watchers would go in side the all function.

We then export the default function, which creates gets injected into bound to the sagaMiddleware.run function in the rootSaga.

Setting Up the rootSaga

We need to add all our sagas to the sagaMiddleware so we can start all of our watchers when the app loads.

In the store folder, create a file called rootSaga.js

import blog from './blog/sagas'

const sagas = [
  blog
]

export const initSagas = (sagaMiddleware) =>
  sagas.forEach(sagaMiddleware.run.bind(sagaMiddleware))

Right now, we only have the one saga. If we set up the Medium store with Saga’s then we would import medium and pass it in to the sagas array.

Note: we don’t need to import every function from our blog/saga.js file, only t action watchers, which we wrapped in an all function which like like a reducer for your sagas.

Actions, The New Face of Blog

Now, that we have some sagas that can watch our actions we need to update our now out of data actions.

If you have been reading along, you know that I follow the fractal file structure which in the case of the store means the store/Blog.js is my public app facing code, and everything in the store/blog folder is private to the store. Sagas aren’t called by the app, the actions are. store/Blog.js currently contains our thunks but those are not necessary anymore, so we can delete them and replace them with the actions that the app will call that will trigger our sagas. We can then remove the actions.js file from our store/blog folder.

Here is the before and after of the Blog.js file

--- Before ---

import * as contentful from 'contentful'
import * as actions from './blog/actions'

const client = contentful.createClient({
  space: 'qu10m4oq2u62',
  accessToken: 'f4a9f68de290d53552b107eb503f3a073bc4c632f5bdd50efacc61498a0c592a'
})


export function loadBlog() {
  return dispatch => {
    dispatch(actions.blogLoading())
    return client.getEntries()
      .then(({items}) => {
        dispatch(actions.loadBlogSuccess(items))
      })
      .catch(error => {
        console.log(error)
        dispatch(actions.blogLoading(false))
      })
  }
}

We get rid of all that logic because that the Saga’s job now, and replace it with a simple actions object that out app can call.

--- After ---

import { createAction } from './Utilities'
import * as types from './blog/types'

export const actions = {
  pending: () => createAction(types.GET_BLOG_ASYNC.PENDING),
  success: (posts) => createAction(types.GET_BLOG_ASYNC.SUCCESS, { posts }),
  error: (error) => createAction(types.GET_BLOG_ASYNC.ERROR, { error })
}

The createAction function doesn’t really do anything more then clean our code up by make it so that no matter how many things are actually passed in as the payload, this function always takes 2 arguments. I think in the future we can use this to help automate some of our async CRUD processes.

One Last Thing, Initialize The Sagas

In our store/index.js

...
import createSagaMiddleware from 'redux-saga'
import { initSagas } from './rootSaga'

const sagaMiddleware = createSagaMiddleware()

export function configureStore() {
  const store = createStore(
    rootReducer,
    composeWithDevTools(
      applyMiddleware(
        sagaMiddleware,
        thunk,
        reduxImmutableStateInvariant()
      )
    )
  )
  initSagas(sagaMiddleware)
  
  return store
}

Originally, we were return createStore, but initSagas need sagaMiddleware to be initialized first. So, we need to create the store then pass sagaMiddleware to initSages which will start all our watchers.

Instead doing something complex in the application root index to call initSagas we can just set a store variable to createStore, then call initSagas before return the store.

That’s it!

Granted, I only just barely scratched the surface of what Sagas can do, this is a good primer to getting them set up and actually working.

Let’s Review

We Installed Sagas
We created some helpers for types and reducers.
Updated our types
Updated our reducer and learned some new technics
Created our first saga
Set up a rootSage
Moved our actions to the public class
Initialized our Saga on app loaded

Yes this is way more complicated, and a fair of extra set up, and has kind of a step learning curve, and…. well you get the idea. But, it’s ultimately a better solution. It’s cleaner(ish), more scalable, more controllable, it’s real-time ready, and it’s infinitely easier to test which we will see in my next() article 😉

Next — Writing Unit Test for a React Blog with Redux Sagas

Replacing Redux Thunks with Redux Sagas was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Photosynthesis

Aaron Klaser — Fri, 23 Feb 2018 16:01:02 GMT

Review

The Short Story: Like It

Welcome to the world of photosynthesis, the green strategy board game! plant and shape the ever-changing forest as you cultivate your seeds and your strategy. Take your trees through their life-cycle, from seedling to full bloom to rebirth, and earn points as their leaves collect energy from the revolving sun’s rays. Carefully pick where you sow and when you grow, as trees in the shadows are blocked from light, and from points. This game features realistic gameplay and beautiful graphics.

BoardGameGeek Rating: 7.4
MSRP: $32.93
Players: 2–4
Ages: 10+
Playtime: 30–60 Min
Publishers: Blue Orange Games
Designers: Hjalmar Hach
Year: 2017

Concept

Growing trees. Players take turns planting seeds and growing them in to trees by spending light points. Each player is awarded light points for each trees that bathe in the sunlight. As the sun rotates around the board, sunlight shines in a specific directs which causes the trees to cast shadows. Sometimes, trees will block the light to other trees and the taller the tree the bigger the shadow. Trees that are in the shadows don’t collect light points. When a tree grows big enough, it can be chopped down and players can collect Score Tokens. The player with highest score after 3 rounds is the winner.

Quality

Not bad considering it’s a bunch of 3D cardboard punch-outs of trees! Our board wouldn’t lay flat and while trying to fix it the backing tore. The fold of the sun piece feels flimsy too, I don’t see it lasting forever.

Artwork

Fun painted cartoonish trees with cute little animals hiding in them. Each player is a different type/color of tree. It all just works. This one of the most beautiful games I’ve very played.

Difficulty

It’s not a very difficult game. Even the strategy is pretty straight forward. The rules were a little confusing at first considering it was only pages. They just were worded weird so it took us a few reads and playing the first 2 rounds to get it, but once we got it it was easy.

Replayability

— Moderately Low

Our Reviews

My rating: 7
by Aaron Klaser

It’s a fun game that can be pulled off the shelf regularly, but it’s only fun to play once in an evening. It’s doesn’t have enough variety to keep it entertaining game after game. It’s kind of like checkers in way that it always starts the same and you always do that same thing. There is no randomness or chance, but there also isn’t enough strategy either. Don’t get me wrong, there is plenty of strategy and it really is a fun game, just not enough for me to play it more than once a game night.

The really winner is the visual appeal of this game. It’s absolutely beautiful, second only to Santorini. The 3D games trees, the color scheme, the little animals in the trees… it’s just fun and pleasant to look at.

One thing really bother me about this game is they called them light point instead of sun points, and they called the sun’s 6 turns around the board a Revolutions and not Seasons. It’s just a missed opportunity.

My rating: 7
by Beth Klaser

We have played Photosynthesis a handful of times since we picked it up at our local board game store {shout out to The Fantasy Shop}. The goal is to plant seeds, grow trees throughout there life-cycle and collect points.

I was a little disappointed that while there was strategy — there wasn’t a ton of strategy. It was based off the luck of planting your trees in just the right places and hoping your opponent didn’t notice until it is too late. If your opponent places there trees (same size or bigger) near yours when the sun comes around the board, it casts a shadow. No points for you — whomp whomp.

The winner for me is the visual aspects of the game itself. It has a unique theme. The trees are 3D. Each tree has something different going on be it — a rabbit, fox, or birds. The colors have that gorgeous fall touch to them all. The mechanics are simple enough that our eight year old could play, if she wanted too. Overall, I wouldn’t hesitate to grab photosynthesis off my game shelf. But, I would not play it more than once or twice in one sitting.

But what does it all mean? Find out how we review the games we play!

Photosynthesis was originally published in Hacked Tabletop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Adding Redux to a React Blog

Aaron Klaser — Thu, 15 Feb 2018 17:45:18 GMT

The React Blog Series: Part Four

This article is part four in a weekly series on building a blog with React and is an extension of the code created in previous parts.

The React Blog Series

Here it is, the moment you have all be waiting for. — Redux!!!

npm install react-redux redux-thunk redux-immutable-state-invariant

Note: You might also have install redux as a dev dependancy. Rumor is yarn solves this problem but you can also manually install it to the depentancies. npm install redux --save-dev

Adding a Store

So this might be an unpopular opinion because I know everyone has a hard on for ReDucks, but thats not the right way to do it. When you put your store files in with your components, you’re combining your Presentation Layer with your application Business Layer and State. If something new comes along that replaces Redux, you won’t have to removed files from all our folders, just remove the whole store. But we will separate our file type in store.

The Fractal Concept

Remember we are using the fractal file structure key value concepts. In the store we are going to follow this pattern with key = public actions (thunks) and value = private (types reducers and actions), which means our app will never talk to the files in our folder. They will only talk to a thunk (the key, the public actions) which will talk to the files in its folder (the value, the private classes). In most cases the our thunk will get data from somewhere and at it to our store.

Confused yet? I though so.

Here is an example of a User store file structure. Our components will only ever talk to User.js, which in turn will talk the files in the user folder. This will make more sense as time goes on.

src 
- app 
  - ... app code ...
- store
  - User.js
  - user
    - actions
    - reducer
    - types

Set Up

In the src folder add a folder called store.

Then add three files: index.js, initialState.js, and rootReducer.js

Setup index.js

import { createStore, applyMiddleware } from 'redux'
import { rootReducer } from './rootReducer'
import reduxImmutableStateInvariant from 'redux-immutable-state-invariant'
import thunk from 'redux-thunk'

export function configureStore(initialState) {
  return createStore(
    rootReducer,
    initialState,
    applyMiddleware(
      thunk,
      reduxImmutableStateInvariant()
    )
  )
}

Setup initialState.js

export default {

Setup rootReducer.js

import { combineReducers } from 'redux'

export const rootReducer = combineReducers({

})

And to hook into the app open the apps index.js in the src folder and and the store and wrap the app.

import React from 'react';
import ReactDOM from 'react-dom'
import registerServiceWorker from './registerServiceWorker'
import { BrowserRouter as Router } from 'react-router-dom'
import App from './App'

// Redux Store
import { Provider } from 'react-redux'
import { configureStore } from './src/store'

import './index.css'

const store = configureStore()

ReactDOM.render((
  
    
      
    
  
), document.getElementById('root'))
registerServiceWorker()

ConfigureStore is our Store’s index.js, we are not currently passing any initial state during set up.

Also, if you need to app to retrieve any initial data, would call it just after we set the store to configureStore.

Redux Blog Store

Now that the easy part is over, let’s roll up our selves and make some magic.

In our store folder create a filed called Blog.js and folder called blog. In the blog folder create three fills: actions.js, reducer.js, and types.js

Let’s start with our types. These are the constants our actions use call dispatches. First, we just need one get load our blog data into our store.

In store/blog/types.js add

/**
* Blog Types
*/

export const LOAD_BLOG_SUCCESS = 'LOAD_BLOG_SUCCESS'

Before we go to far let’s add a blog object with an empty array for posts as our initial state for blog. This will be passed when setting up our reducer. It also allows the app to load without data yet with out throwing null exceptions.

In store/initialState.js add

export default {
  blog: {
    posts: []
  }
}

Next, let’s set up our reducer. This is what updates our state which is where our data gets stored. The actions will call these and via a switch statement it will look for the type that was called by the action.

In store/blog/reducer.js add

/**
* Blog Reducer
*/
import initialState from '../../store/initialState'
import * as types from './types'

export default function blogReducer(state = initialState.blog, action) {
  switch (action.type) {
    case types.LOAD_BLOG_POSTS_SUCCESS:
      return {
        ...state,
        posts: action.posts
      } 
    default:
      return state
  }
}

Next, we need to set up an action to dispatch the type and set its data as the payload (posts).

In store/blog/actions.js add

/**
* Blog Actions
*/
import * as types from './types'

export function loadBlogSuccess(post) {
  return { type: types.LOAD_BLOG_SUCCESS, post}
}

Now, we need to include this in our rootReduce. The rootReducer combines all the store reducers into one giant mega reducer that creates a global state accessible every where in the application.

In store/rootReducer.js add

import { combineReducers } from 'redux'
import blog from './blog/reducer'

export const rootReducer = combineReducers({
  blog
})

Notice we didn’t import it as blogReducer, because what ever you call it in the combineReduces is how you access it in the rest of the app. Export default is what allows us to name things anything we want when we import the default function. We could have imported it as blogReducer a then the combineReducers functions done blog: blogReducer, but I personally think this looks better. #CodeIsArt

Testing that Redux is Working

Right now our code is working. It doesn’t do anything yet because its not actually doing anything we can see, but it is working and I can prove it.

First you need the Redux Dev Tools extension for chrome. https://github.com/zalmoxisus/redux-devtools-extension

npm install --save-dev redux-devtools-extension

Then we need to hook it up. In store/index.js we are going to remove the initialState because we will be setting those in the reducers of each store, we will wrap our middleware with composeWithDevTools function.

import { createStore, applyMiddleware } from 'redux'
import { rootReducer } from './rootReducer'
import reduxImmutableStateInvariant from 'redux-immutable-state-invariant'
import thunk from 'redux-thunk'
import { composeWithDevTools } from 'redux-devtools-extension';

export function configureStore() {
  return createStore(
    rootReducer,
    composeWithDevTools(
      applyMiddleware(
        thunk,
        reduxImmutableStateInvariant()
      )
    )
  )
}

Then install the extension in chrome and open the chrome inspector (I usually right click on the page and click Inspector). In the top nav you should now have Redux option.

Click it and refresh your app. The Redux tab sometimes has to be open when the app loads for it to work, this is because the connection is established on site load in the createStore(…) function.

Now, you should see your Redux state and history. It defaults to Diff so click the State tab and you should see your default object

Pretty cool, right!

Putting Blog Data in the Blog Store

Remember that in Blog.js file is the public actions (the thunk) of our store. This is where we will put our thunks and retrieve our data when the site loads.

We can reuse some of our logic from from app/Blog.js because it will no longer need to make the call to Contentful any more. That will happen in our thunk.

Let’s set up our thunk. Open store/Blog.js and add

import * as contentful from 'contentful'
import * as actions from './blog/actions'

const client = contentful.createClient({
  space: 'qu10m4oq2u62',
  accessToken: 'f4a9f68de290d53552b107eb503f3a073bc4c632f5bdd50efacc61498a0c592a'
})

const error = err => console.log(err)

export function loadBlog() {
  return dispatch =>
    client.getEntries()
      .then(({items}) => {
        dispatch(actions.loadBlogSuccess(items))
      })
      .catch(error)
}

The thunk automatically passes dispatch into our functions which is what the first parameter there is doing.

This code will make the call out to Contentful and the send that data to the loadBlogSuccess actions which will store the data on our blog state under posts.

But it wont happen automatically, we will need to call this function when the site loads.

We will do this by adding a line to our root index.js file

...

// Redux Store
import { Provider } from 'react-redux'
import { configureStore } from './store'
import { loadBlog } from './store/Blog'

import './index.css'

const store = configureStore()
store.dispatch(loadBlog())

ReactDOM.render((

...

We are telling the store that once its created, to dispatch the loadBlog() function.

When you refresh the app and check that Redux dev tools you should now see some data in blog > posts

Using the Store in a Component

This is a pretty easy step. Redux give us a function that we can use called mapStateToProps that, as you can probably guess, maps our redux state… to our page props. Then we “connect” the mapStateToProps and Blog.js to Redux.

Here‘s the magic, open app/Blog.js and remove our old code to get posts and add/update 8 lines of code.

import React from 'react'
import { connect } from 'react-redux'
import * as contentful from 'contentful'
import BlogItem from './blog/BlogItem'
import PageHeader from './components/PageHeader'
import PageContent from './components/PageContent'

class Blog extends React.Component {
  render() {
    return (
      
        
          Your standard JavaScript programming blog, albeit, probably not very good, but I will at least try to keep it entertaining. This blog is a chronological mix of random posts on Angular, React, Functional Programming, and my project walkthroughs.
        
        
          { this.props.blog.posts.map(({fields}, i) =>
            
          )}
        
      

    )
  }
}

function mapStateToProps(state, ownProps) {
  return {
    blog: state.blog
  }
}

export default connect(mapStateToProps)(Blog)

Blammo! Redux!

Using Blog State Correctly

I will be the first to admit that when I first started using Redux I was using it as a data store, and it’s so much more then that. It is your apps state, where its going, where its been, what its doing, what it knows… Using it only to store data is an insult to its existence. For example, our app runs fine right now because Contentful is awesome and fast and we only have very small about of data, but what if we had a lot of data or a slow connect. we don’t want to load a blank play for the user.

Let’s created a blog state for loading, that is we can display a loading icon while its getting data from Contentful.

store/initialState.js

export default {
  blog: {
    loading: false,
    posts: []
  }
}

store/blog/types.js

/**
* Blog Types
*/
export const BLOG_LOADING = 'BLOG_LOADING'
export const LOAD_BLOG_SUCCESS = 'LOAD_BLOG_SUCCESS'

store/blog/reducer.js

/**
* Blog Reducer
*/
import initialState from '../../store/initialState'
import * as types from './types'

export default function blogReducer(state = initialState.blog, action) {
  switch (action.type) {
    case types.BLOG_LOADING:
      return {
        ...state,
        loading: action.isLoading
      }
    case types.LOAD_BLOG_SUCCESS:
      return {
        ...state,
        posts: action.posts,
        loading: false
      }
   default:
     return state
  }
}

Yes. State only contains posts and loading, yet we still spread it out. If you where keeping score, you might have noticed it earlier. It’s a good practice, because we are setting a new state object every time. Buy always spreading state first, we get all the previous values and don’t forget any, then the new fields simple overwrite the previous values. Like Object.assign({}, previouseState, { …newStateValues})

store/blog/actions.js

/**
* Blog Actions
*/
import * as types from './types'

export function blogLoading(isLoading = true) {
  return { type: types.BLOG_LOADING, isLoading}
}

export function loadBlogSuccess(posts) {
  return { type: types.LOAD_BLOG_SUCCESS, posts}
}

We are setting isloading to a default of true so we don’t we won’t normally have to pass any data in when dispatch blogLoading. BUT, by making it so we can pass in something like false, means we don’t have to create an action to set loading to false, like say if there was an error with loading.

store/Blog.js

import * as contentful from 'contentful'
import * as actions from './blog/actions'

const client = contentful.createClient({
  space: 'qu10m4oq2u62',
  accessToken: 'f4a9f68de290d53552b107eb503f3a073bc4c632f5bdd50efacc61498a0c592a'
})

export function loadBlog() {
  return dispatch => {
    dispatch(actions.blogLoading())
    return client.getEntries()
      .then(({items}) => {
        dispatch(actions.loadBlogSuccess(items))
      })
      .catch(error => {
        console.log(error)
        dispatch(actions.blogLoading(false))
      })
  }
}

So we need to do some rearranging, we will clean this up later, but we need to able to call dispatch to call our actions for blogLoading.

Now, you should see some additional actions being fired off in your Redux Dev tools.

Update the View to Add a Loading Icon

Back in app/Blog.js lets set up some placeholder text to make sure our logic works.


  
Your standard JavaScript programming blog, albeit, probably not very good, but I will at least try to keep it entertaining. This blog is a chronological mix of random posts on Angular, React, Functional Programming, and my project walkthroughs.
  
  { this.props.blog.loading
    ? Loading

    : 
        { this.props.blog.posts.map(({fields}, i) =>
          
        )}
      
 }

We are wrapping the previous code with ternary operator to handle the if statement. This means, if loading is true, we will show the loading div, else we show the content dev.

If you’re like me, Contentful is just too fast and you can’t see it. We can wrap the dispatch on the getEntries success promise with a timeout. setTimeout(() => dispatch(actions.loadBlogSuccess(items)), 5000)

Now you should be able to see the loading div.

Or, you can the history jump feature in the Redux Dev Tools. I’m gonna let you discover that little gem on your own ;)

Now, in app/components create Loader.js which will be a styled component for our spinner.

https://medium.com/media/602c776f6b12353807670a0ee0ad0831/href

Now back in our app/Blog.js let’s add the spinner. Replace

with

and don’t forget to import the loader import { Loader } from ‘./components/Loader’

The Loader defaults to white, so you need to either hard code the color or using Bulma we can just give it the class has-text-$color (like has-text-primary).

I found a bug :(

Back in the clean up phase of Building a Blog with React and Contentful I forgot to change the text for Read More and Back to Blog in the Blog Items Nav.

It’s an easy fix with a simple ternary operator in the using the to prop.

In app/blog/shared/BlogNav.js can the Link to this


  { to === '/blog' ? 'Back to Blog' : 'Read More'}

Add the Store to the Medium Page

Now we can do the exact same things for out Medium page. I’m not going to show you each and every step because that’s not how we learn, but I will list them out for you.

Step 1: Create types
Step 2: Add state to initial state
Step 3: Set up reducers
Step 4: Set up action
Step 5: Add reducers to rootReducer
Step 6: Setup our thunk (hint below)

import * as actions from './medium/actions'
import axios from 'axios'

const fetchPosts = () => axios.get(`https://cors.now.sh/https://us-central1-aaronklaser-1.cloudfunctions.net/medium?username=@aaron.klaser`)

const setPosts = ({data}) => Object.values(data.payload.references.Post).map(
  ({ id, title, createdAt, virtuals, uniqueSlug }) => Object.assign({},{
    title,
    createdAt,
    subtitle: virtuals.subtitle,
    image: virtuals.previewImage.imageId ? `https://cdn-images-1.medium.com/max/800/${virtuals.previewImage.imageId}` : null,
    url: `https://medium.com/@aaron.klaser/${uniqueSlug}`
  })
)

export const loadMedium = () => async dispatch => {
  dispatch(actions.mediumLoading())
  const data = await fetchPosts()
  return dispatch(actions.loadMediumSuccess(setPosts(data)))
}

Step 7: Add state to component

Test it and move on with life. You are now a Redux master!

Let’s Review

Add Redux and friends to your project.
Set up the Store using fractal file sturcture
Set up the store’s types reducer and actions for loading data
Set up the store’s thunk, which is our public actions class
Add the store to the page component
Added a loading state and loading animation
Fixed a previews bug
Added the store to the Medium page

Next — Replacing Redux Thunks with Redux Sagas

Adding Redux to a React Blog was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Import your Medium Feed into React

Aaron Klaser — Mon, 12 Feb 2018 16:30:31 GMT

The React Blog Series: Part Three

This article is part three in a weekly series on building a blog with React and is an extension of the code created in previous parts.

The React Blog Series

If your not blogging on medium yet, you should. It’s so easy.

This week we are going to add a feed to our website so we have a kind of alternative blog.

First let’s look at what a medium feed looks like. We can and medium content back in JSON format by adding ?format=json to the end of the url. Here is my feed.

https://medium.com/@aaron.klaser/latest?format=json

This will return a massive chunk of JSON, but we only care about payload.references.Post

I think it’s fair to note that this is not actually a “feed”, this is basically the content that Medium uses to display previews of my latest post on my Medium profile, not the complete posts themselves. Medium provides an RSS feed for which does contain more information like a traditional blog feed, however it can not be returned any JSON, only XML. I like the idea of this just being previews with links back to my Medium articles, on Medium, and it’s a bonus to not have to parse XML. But, if you would like to use the actual Medium feed these concepts are almost identical and you would use the url https://medium.com/feed/@aaron.klaser

But we need a page to put it on. I already have a tab for it in the Nav we just need to create a page to put it on. The basic set up follows a lot of the steps in my last article, so I’m going move quickly though the basic page setup.

In the app folder, create a file called Medium.js

import React from 'react'
import PageHeader from './components/PageHeader'
import PageContent from './components/PageContent'
import axios from 'axios'

class Medium extends React.Component {

  state = {
    posts: []
  }

  componentDidMount() {
    this.fetchPosts().then(this.setPosts)
  }

  fetchPosts = () => axios.get(`https://cors.now.sh/https://us-central1-aaronklaser-1.cloudfunctions.net/medium?username=@aaron.klaser`)

  setPosts = response => {
    this.setState({
      posts: response
    })
  }

  render() {
    return (
      
        
          Medium is where I ramble and rant and tell stories. I orginally was going to use it as a coding blog, I don't like having to use Gist for all my code snippets. So I created this site.
          


          
            View My Medium
            
              
            
          
        
        
          {JSON.stringify(this.state.posts, null, 2)}

        
      

    )
  }
}

export default Medium

Then set up the routing for this page and update the item for Medium to point to this page.

This was not easy to figure out

So as we are building this locally Medium blocks localhost for cors. You can tell fetch to run no cors mode but then you get an opaque response with no data. I found that I could get around this by running everything through an express server but I don’t want my site to need a back end. I also tryied running it through something like cors-anywhere and cors.now. They where just blocked, and for good reasons honestly.

Serverless Architecture to the Rescue

I was able to fix this using Firebase Cloud Functions to make the call for me. However, firebase still throw cors errors but they where not blocked by cors.now.

My function looks like this, it’s ugly but I got it working and I’m moving on.

Medium returns a weird prefix ])}while(1); to prevent JSON Hacking (:P) so we’ll just remove that and return our data.

const functions = require('firebase-functions');
var request = require('request');

exports.medium = functions.https.onRequest((req, res) => {
  if(!req.query.username) {
    return res.status(400).send('Error: You need to include query param ?username=@yourUsername');
  }

  const url = `https://medium.com/${req.query.username}/latest?format=json`;

  return request(url,(error, response, body) => {
    const prefix = `])}while(1);`
    const strip = payload => payload.replace(prefix, ``)
    res.send(JSON.parse(strip(body)));
  });
})

I have set up and endpoint in firebase functions that you can use or you can try to create your own. I might even create an article on it because it turns out its pretty cool.

https://cors.now.sh/https://us-central1-aaronklaser-1.cloudfunctions.net/medium?username=@yourUsername

Just update your username and you should see your json in the pre block.

Extracting the Data For Our Posts

There is an easy way but its dirty, then there is a hard(ish) way but it’s clean.

The Easy Way:

Use Object.values() to convert the Posts node to an array of objects. This gets use our data but its ALL our date and we wont be able to spread that out over our MediumItem (we will build shortly)

setPosts = ({data}) => {
  this.setState({
    posts: Object.values(data.payload.references.Post)
  })
}

But when you run the app you will see the pre blocks have the extracted Post data, but that also have a mountain of data you don’t need. The hard way solves this.

The Hard Way:

(Recommended) Let’s extract the only data we need in our post. That would be: createdAt, image, title, subtitle, description, and the url back to the post on Medium.

setPosts = ({data}) => {

  const { Post } = data.payload.references

  const posts = Object.values(Post).map(({ id, title, createdAt, virtuals, uniqueSlug }) => Object.assign({},{
      title,
      createdAt,
      subtitle: virtuals.subtitle,
      image: virtuals.previewImage.imageId ? `https://cdn-images-1.medium.com/max/800/${virtuals.previewImage.imageId}` : null,
      url: `https://medium.com/@aaron.klaser/${uniqueSlug}`
    })
  )

  this.setState({
    posts
  })
}

Now when we run our app, it should only print out the five fields we need from the giant blob of JSON, all ready to be spread out in our MediumItem object which we will build…

Now!

Building the MediumItem Component

In our app folder, create a medium folder and inside that create MediumItem.js

This will look similar to our blog Item, but since medium doesn’t give us the content, we won’t need a MediumPost like we did with the Blog, so we wont have any shared items and we will just put it all in this one component.

import React from 'react'
import moment from 'moment'

const MediumItem = ({title, createdAt, subtitle, image, url}) => (
  
    { image
    ? (
         
           
         

       
)
     : "" }
    
      
        
        {title}

      

    

    
      { subtitle }
    

    
      
        
          {moment(createdAt).format('MMM Do')}
          {moment(createdAt).format('YYYY')}
        

      

      
        
          Read on Medium
        
      

    

  


)

export default MediumItem

It should look something like this

And there you have it kids! You now have a Medium feed in your Blog that links back to your Medium posts. Start clapping!!

Let’s Review

We set up a page for our Medium Feed
We linked to Serverless Function to retrieve our Medium feed
We extracted the data we need from our Medium content
We set up a simple MediumItem component.

Next — Adding a Redux to a React Blog

Import your Medium Feed into React was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Who is Hacked Tabletop

Aaron Klaser — Mon, 05 Feb 2018 17:27:24 GMT

And What is Our Future?

At the time of writing this, Hacked Tabletop is a husband-wife combo featuring me (Aaron Klaser) and Beth Klaser. We are not writers or bloggers by any means, but instead we are passionate board game enthusiasts who just want to give back to other board game and tabletop enthusiasts. Over the last 2 years of diving head first into our addiction of buying almost any game that sounded interesting, we have noticed a few gaps in the community.

We know there are 100’s, maybe 1,000’s of people out there reviewing games. We have to bring it to be able to make a name for ourselves, but we may have a few tricks up our sleeves to help set us apart from all the others.

The Problem

My biggest complaint about board game reviews has always been the quality of reviews, visually. Most reviews are well written but wither it’s the video or the photos, they are all just… crap. I’m sorry. I know how hard everyone works to put these together,I mean no insult, but it’s time to step it up.

Another common issue is the lack of quality How-To videos. Games these days are WAY more difficult then they were when I was kid. The exceptions are Watch It Played and Wil Wheaton’s Tabletop — tutorials are either not well explained or the quality is to poor for it to be beneficial.

Our Solutions

We are planning to seriously set up quality. Much to my wife’s dismay, we have invested butt-loads of money into gear; 4k Cameras, professional lighting, editing software, streaming rigs, and web cams. You will no longer see poorly lit photographs from terrible angles or some cheap web cam sat in the middle of the of room that’s really hard to see and hear.

There is going to be some trial and error to get it right, but we currently have over 160+ games in our constantly growing collection of board games to practice with.

We plan to bring you

Reviews & Previews
Unbiased reviews and previews including high quality professional photographs. We don’t think it’s the greatest game ever made just because it has mini’s. Although, I (Beth Klaser) do love some mini’s. We have designed a processes to determine our rating — which includes playing a game at least five times no matter how terrible the game may be. Learn More

How To’s & Unboxings
This is not new to the community. However, we will be using professional equipment such as lighting and a 4k camera to bring the highest quality to our tutorials, How To’s, and unboxings.

Learn it Together
Learn it Together well be a live streamed web series where we sit down and try to learn a new game together live on Twitch (and maybe a few other places).

HackedTabletop.com

Don’t worry, we have a site coming! Medium is our temporary home. We ended up choosing Medium because it is easy to set up and because reviews can be written fairly quickly. I (Aaron) am a web developer by day, and have been for the last ten years. I am building our site using React and Contentful. There may even be an easy to use app in the works.

Want Your Gamed Featured?

Featured games will get a little extra attention. They will get a photo of there game displayed front and center on our page.

We plan to have a game featured starting on March 1st, 2018. If you are interested in having your game featured on our site, drop a line to Hackedtabletop@gmail.com.

Who is Hacked Tabletop was originally published in Hacked Tabletop on Medium, where people are continuing the conversation by highlighting and responding to this story.