While it may feel counter-intuitive to structure data like this, we must remember that Javascript doesn’t actually guarantee order of keys in an object. In addition, insertions, replacements, and removals (especially in the context of maintaining immutability, which in Javascript requires cloning) is significantly more efficient with Objects than Arrays.

This is all fairly standard for initiated Redux users. Where the documentation doesn’t explore is the problems when 2 independent views of the same, de-duplicated entity must exist at the same time and independent meta-request information like fetching status, pagination status, must be tracked independently.

At Grovo we have been using an abstract structure we’ve taken to calling Key Windows.

The concept is fairly simple, and in a way if we’re thinking of normalization as SQL tables, we could think of this as a ‘view’. For a given entity type there are multiple possible lenses to view the data: a paginated table, a type-ahead dropdown, a detail view, a special widget. We consider these lenses a ‘window’ into the raw de-duplicated universe of entities.

The actual structure is extremely simple and an extension of the official documentations suggestion, merely replacing the allIds with an arbitrary number of meta-information containers and a keyWindows top-level tracking all currently present windows.

Where the power comes in is the recognition that there is a very strong attachment between key windows (“what am I looking at”) and API requests. It makes sense to begin to attach all sorts of meta-information about requests and views of data inside the key window data structure like fetching status and pagination.

Starting with a trivial example: I’m viewing a paginated list of Users, but our UX calls for a little widget that shows a list of “managers” at the top. Because the managers potentially are not currently in the page, we cannot simply replace the byId portion of the store lest we accidentally wipe out our managers, and we cannot simply show all users in byId in the table lest we show incorrect information. Our store would then look something like the following:

This structure gives us a number of benefits:

• We can track request/fetching status of the browse users table and the managers widget independently
• We can track the pagination status of the browseUsers independently as well, potentially allowing a single view to have multiple paginated data sets
• Maintenance of the byId key on the store is a simple concat of new entities on request complete
• The ids array in each key window is a simple replace on request complete
• The ids array continues to maintain any intrinsic ordering received from the API endpoints

Implementation Notes

We have found that fully adopting this structure required a few changes to our actions/action creators, namely we now need the entity responsible for dispatching a given action also needs to explicitly declare a key window name. In the above example, fetchUsers({query}) might soon become fetchUsers({query}, 'browseUsers'). However “explicitly declare” can also mean that something like fetchManagers() can always use 'allManagers' internally. Simply put the action payload needs an explicit window name.

Because the keyWindow property on the action is both common and explicit even on the subsequent ‘receive’ action(s), it in effect tags an entire request lifecycle and simplifies our reducer allowing two supposedly distinct fetch initiation actions to share a common implementation.

One addition item to note, this relies on your side effect system emitting the receiveEntities() action to namespace the entities behind their entity name (see lines 24 and 30) above, however you can always still do a simpler receieveUsers() action. I personally have just become a fan of a singular receive action for multiple fetch initiators.

Further Improvements

There are of course ways we can build on this concept:

1. Tracking and handling errors can now use the the key windows to isolate and provide granular error reporting and recovery
2. Tracking the unique list of key window names seems like overkill, but allows for you to deterministically loop through all key windows and allow for garbage collection via a releaseKeyWindow() type action
3. Since key window names can be anything, they can be another entity’s ID to provide some semblance of foreign key type relationship for quicker lookups

A Word on Naming

We internally called this concept “key windows” after a period of debate that was longer than I care to admit. We initially called them views (like SQL views) but found the word view is used quite often in frontend work (who knew) and caused lots of communication problems and unclear messages. My problem with key windows is it doesn’t fully explain what it is in the name itself, but I’m not sure if anything better exists. I’m open to suggestions!

Naming really is the worst problem in computer science…

Recently a project built entirely in React required the rendering of a fairly non-standard graph. Naturally D3 is my go-to, however unfortunately resources are sparse and one of the few good articles on the subject (On D3, React, and a little bit of Flux by Shirley Wu) was a little feature-rich for my tastes, especially because I’m not particularly strong in D3 and my graph was NOT as complex as the visualizations Shirley was tackling.

With a bit of learning from her post, slamming my forehead against a wall for a day, and a particularly late flight to LAX, I hit an aha moment that helped with my approach.

NOTE: this article assumes you’re fairly competent with React, but not necessarily super competent with D3.

React was a solid re-shift in how I approached UIs. While I had already been pursuing a “application first, DOM as representation of application” approach to my web development, React was a feet first polar-bear dip to my previous ginger toe-dipping.

The problem is on the surface level D3 felt like the old way and here I am in React trying to do things the new way and not seeing the connection, until I realized something:

D3 is not an SVG drawing lib*, D3 is a set of utils to generate data for SVGs

I was approaching learning D3 like I approached Raphaël.js, when instead I realized I needed to treat it closer to a lodash. D3 gave me things like scale calculators and SVG path syntax generators, the actual SVG elements I can lay out myself (hint, React is pretty good at those).

React and D3 exist in 2 separate spheres: React handles the actual elements (how many lines need to be plotted), D3 handles the properties (what does the line actually look like).

Along these separations, we want React to handle the actual SVG elements.

To start, lets begin with our chart:

We build our component to accept a width and height and of course our input data. For now we’ll keep to a simple array of objects with the keys x and y. Finally, simply enough we drop an SVG tag.

An empty graph is pretty boring, so lets add a line. If you’re up on your basic SVG knowledge, a line is simply a path with a stroke:

Which we can theoretically compose into our chart:

Now the problem is this line isn’t actually drawing anything yet, so lets go back and update our Line component to draw.

This is where D3 enters into the responsibilities picture. In order for the line to have shape, we need to set the d property of the path element. Luckily D3 provides a utility to generate this property: d3.svg.line().

The full documentation is beyond the scope of this blog post, however the utility is fairly simple: d3.svg.line() generates a function which, when given an array of data, maps the data into an SVG path specification.

A critical aspect, however, is transforming the data according to the scale of the graph. Namely, I can’t just plot the raw data, I need to calculate a pixel positioning (do we have margins, etc). Above you’ll notice I’ve put in a placeholder function call for scaleX and scaleY. But how do we get this information?

Yet again, D3 provides a utility d3.scale which does something similar (produces a function where you can pass in a value and have it transformed into an x/y coordinate according to the scale configured). But there’s a problem: scale is inherently tied to the chart, not the line. So lets drop into the Chart and build out the scale:

This is fairly rote D3 ripped straight from newbie tutorials, make the scale perfectly fit the data set and perfectly fit the width and height of the SVG.

Now here is where you might be tempted to just pass in the X and Y scales as props into the Line, maybe like:

<Line data={this.props.data} xScale={this.getXScale()} yScale={this.getYScale()} />

But this would get old very fast as you added more lines, etc.

Switching mental contexts (wait for it) back to React, we have this fun feature called… context! If you’ve used almost any Flux framework or react-router, you’re probably already familiar with context. You may not be familiar with the method getChildContext() which you can define on a component to inject next context into all of its children. Convenient!

So lets do exactly that, lets have the Chart define the X and Y scale as a context related specifically to this chart:

NOTE: You MUST provide the childContextTypes otherwise React will yell at you very loudly!

Now that we’ve made the X and Y scale available, lets update our line to simply use the context:

Congratulations, you’ve taken your first step to drawing a line on an SVG canvas!

With a tiny bit of syntactic sugar and sample data generation, you can now watch your simple chart at work:

While this is great, we need more complex charts than this. Or at least I did, particularly in plotting points on top of multiple lines (some linear, some interpolated).

Recently an age-old cycle re-emerged in the PHP community. The classic tales of “beer as currency” and the problems that can sometimes arise was recently written about by Pablo Godel. And the one refrain I heard from the discussion that ensued on Twitter is that there is a lot of discussion about the problem but little advice on solutions.

Jordi Boggiano on Twitter: "@dcousineau @pgodel Pablo's post is a good call to action but it's lacking advice to organizers so if you complete that it'd be good."

Good reminder by @pgodel on drinking culture in PHP/tech http://www.pablogodel.com/2014/11/11/lets-stop-creating-alcoholics-in-php/ ... and why I'm proud of how we structure @lonestarphp events

For those of you that aren’t familiar with me, I love beer. So do my co-organizers. And I also love the tech community and conferences. So naturally I enjoy being able to link up with old and new friends and share beers and comraderie.

However there are those in the community that for a multitude of reasons don’t drink, and I really want to have fun with them too and as an organizer I want to be inclusive and inviting to them.

Decisions Are Like Water

The decisions we make as humans are like water: they tend to follow the path of least resistance. If the only social activity of your conference is an open bar in a big empty room with a sponsor slideshow in the corner, the easiest decision to make is to drink. And for most of us that’s not an issue, but for those of us that don’t drink it can feel exclusionary due to the difficulty of finding non-alcoholic alternatives, and it can be dangerous for the silent members of the community who struggle with alcohol.

At Lone Star PHP we love both our beer and our friends and have made it an internal goal to try what we could to make our after parties and social events as inclusive non-drinkers and drinkers alike while keeping it safe for those who struggle. To do this we make having fun WITHOUT alcohol the path of least resistance.

1. Keep your social event on-site. While sometimes this is not possible due to venue restrictions, we keep our after party on-site and not in a bar. This helps out-of-towners feel less isolated as well since they don’t have to navigate an unfamiliar city and gives them the option to control their own schedule.
2. Start the social immediately after the closing talk. “We’re going to give people time to drop their stuff off and give ourselves time to set up” was a great rationalization our first year of Lone Star at our current venue but it utterly destroyed our social event: the only attendees were the speakers and a handfull of locals. The rest? Left to go to bars, leaving the non-drinkers feeling isolated.
3. Non-alcoholic drinks as a first class citizen. We actually prided ourselves on making sure that our open bar’s non-alcoholic options were top-tier and potentially more inviting than the alcoholic option. Jake, Chris, and I actually had a lot of fun selecting high-quality sodas and lemonades like Virgils, Dublin Dr. Pepper, Mexican Coke, and Hubert’s Lemonade. The bartenders were expressly told to use the crappy 2-liter bottles for cocktails, the nice stuff was on display and for non-drinkers only.
4. Provide actual activities and games. We filled our main room with board games, an Xbox with a Kinect, and Cornhole to provide things to do. The last thing we wanted was an empty ballroom whos only decoration are open-bar carts. What we wanted were as many options as possible so those who don’t drink can have fun with everyone else without feeling singled out or conspicuous.
5. Keep the alcohol to the side/out of the activity spaces. This was, for us, dictated by the layout of our event space but it ended up working out really well. The bar carts were in the hallways outside of the main room so those playing boardgames and socialize could do so withotu the constant distraction of the bar carts. It was such a minor thing to make a quick trip to the hallway to grab a beer, but it helps those who struggle with alcohol to feel integrated without constant temptations.
6. Provide food. You want to keep as many of your attendees at your afterparty for as long as possible. If there is no food they’re going to leave in groups to go eat, and usually that trip is to a local bar. While this is fine, again, the non-drinkers and out-of-towners aren’t inclined to leave and go to a strange bar. The more people that stay at the afterparty the more fun it is for everyone.
7. Ensure the bar tenders are empowered and responsible enough to cut off excessive drinking. This is something that is hard to keep track of and is something we constantly struggle with. Some years there are 0 problems, and some years someone comes along and throws a wrench in everything. Sometimes the best you can do is just repeat it out-loud to yourself so you feel okay helping a friend by cutting them off.

These aren’t hard-and-fast rules certainly. With the above #5 we actually had an exception in that we had Dean Brundage of New Republic Brewing move his tap station to the main room one year so he and his lovely wife could socialize with the rest of the party while serving his beer. It massively helped, however, that the person serving the beer was familiar with the tech community and could interact and socialize. Which was a mistake we made in a later year having one person manning the hombrew beer station who was unfamiliar with the community and caused some uncomfortable friction.

And sometimes you can’t follow #1 because of limitations with where your event is held and the costs of your event space. EmpireJS was held in New York City, an area famous for expensive venues, and had severe restrictions but still had an excellent after party in which they rented a boat for a cruise around the Statue of Liberty and the Brooklyn Bridge. An amazing experience for out-of-towners and fun whether you were drinking wine or grape juice.

Conferences Can Still Have Their Beer And Drink It Too

The goal is not to get rid of alcohol all together, or hide it away shamefully. The goal is to provide options and be active and responsible as organizers knowing the after-party is as important as the primary conference experience.

The homebrewers and beer aficionados among us (namely, the entire Lone Star PHP organizing team) can still sit around drink Omni’s creations and discuss our favorite beers, and the last thing we would want to do is get rid of that. But we also still want to hang out with our friends who just want a rootbeer and a round of Munchkin. Or a vodka-soda and Dance Revolution. Or a glass of wine and Cornhole.

And people will still have fun. And there will still be after-after-parties at a bar down the street. Bottles of beer will be traded, homebrews will be tasted, and your attendees will be none the wiser to your plans and machinations.

A Note On “Promoting” Drinking

Before I close out, I want to spend a few sentences on the phrase “Promoting Drinking” in regards to conferences. Whether intentional through marketing materials or unintentional by lack of options, if your only afterparty is at a bar, or in an empty room with bar carts, you are promoting drinking purely by virtue of not promoting anything else.

As conference organizers we need to be aware that people read into everything we do, and everything we don’t do, and work hard to craft the whole experience. Conference experiences have been ruined more often in the evenings than they have during the day and we must be aware that our responsibilities start when the first plane touches down and don’t end at 5pm.

While it’s not our responsibility to nanny our attendees (they are adults after all) it is our responsibility to make sure good decisions are as easy as possible to make. And that means more effort on our parts providing a relaxed and inclusive atmosphere and letting gravity take its course.