How to Write an A-Frame VR Component

A-Frame is a WebVR framework that introduces the entity-component system (docs) to the DOM. The entity-component system treats every entity in the scene as a placeholder object which we apply and mix components to in order to add appearance, behavior, and functionality. A-Frame comes with some standard components out of the box like camera, geometry, material, light, or sound. However, people can write, publish, and register their own components to do whatever they want like have entities collide/explode/spawn, be controlled by physics, or follow a path. Today, we'll be going through how we can write our own A-Frame components.


Upon first seeing A-Frame, branded as "building blocks for the web" displaying markup like <a-cube>, developers may conceive A-Frame as yet another 3DML (3D markup language) such as X3Dom or GLAM. What A-Frame brings to the game is that it is based off an entity-component system, a pattern used by universal game engines like Unity which favors composability over inheritance. As we'll see, this makes A-Frame extremely extendable.

And A-Frame VR is extremely mindful of how to start a developer ecosystem. There are tools, tutorials, guides, boilerplates, libraries being built and knowledge being readily shared on Slack.


Today, the Mozilla virtual reality team (MozVR) released an open-source library for beginners and developers alike to easily create WebVR experiences. It's called A-Frame. A-Frame wraps three.js into custom elements so the HTML and DOM manipulations that web developers are accustomed to can be used to create 3D VR scenes in the browser. Under the hood, A-Frame brings the entity component system, a pattern common in game development, to the DOM. It supports both desktop, if you got a Rift, or easier, you can even use a smartphone. This post serves as a speed-through introduction of A-Frame, refer the documentation at any time for much more detail.


Using react-router with redux

I'm working on submission and reviewer tools for FirefoxOS add-ons, which I'd like to shout out is the most exciting thing to hit FirefoxOS yet. It'll enable a customization community as powerful as CyanogenMod yet be much more accessible.

For this project, I wanted to port our Flux framework from Flummox to Redux while using react-router. I always struggle with getting react-router to pass Redux-related context to the handler components. Having done this twice and running into many pitfalls, I am sharing my experiences to prospective struggle-bus riders.


We have been building an increasing amount of Custom Elements, or Web Components, over at the Firefox Marketplace (using a polyfill). Custom Elements are a W3C specification that allow you to define your own HTML elements. Using Custom Elements, rather than arbitrary JS, encourages modularity and testability, with portability and reusability being the enticer.

Over the last several months, I worked on revamping the UI for the Firefox Marketplace. Part of it was building a custom dropdown element that would allow users to filter apps based on platform compatibility. I wanted it to behave exactly like a <select> element, complete with its interface, but with the full license to style it however I needed.

In this post, I'll go over Custom Elements, introduce an interesting "proxy" pattern to extend native elements, and then compare Custom Elements with the currently reigning Component king, React.