| { | |
| "basics": { | |
| "name": "Thomas Davis", | |
| "label": "Web Developer", | |
| "image": "https://avatars0.githubusercontent.com/u/416209?s=460&u=38f220a2c9c658141804f881c334c594eb1642ac&v=4", | |
| "summary": "I'm a full stack web developer who can build apps from the ground up. I've worked mostly at startups so I am used to wearing many hats. I am a very product-focused developer who prioritizes user feedback first and foremost. I'm generally very flexible when investigating new roles. I am also deeply passionate about web accessibility and believe in creating inclusive and user-friendly experiences for all users.", | |
| "website": "https://lordajax.com", | |
| "email": "thomasalwyndavis@gmail.com", | |
| "location": { | |
| "city": "Melbourne", |
| export const UserSchema = z.object({ | |
| id: z.string(), | |
| createdAt: z.string().datetime(), | |
| displayName: z.string(), | |
| role: z.enum(["Viewer", "Editor", "Admin"]), | |
| }); |
This is our JS tracking library that we use to define and send events to Backtrack. Backtrack then forwards the events to Mixpanel.
It's available from the rest of Polecat under an alias '@Tracking'.
The main reason we have this library is to add order to our Mixpanel events. For that reason events are defined with a schema. The properties dispatched with events are then validated against the schema in Backtrack before being forwarded to Mixpanel.
Until now we've been on React Router V1. While some parts of the API look similar between the two versions they are very different in a lot of ways.
First of all, there are now two packages for React Router. In a similar way to how react-dom was split from react, react-router is now the core (cross-platform) library with react-router-dom being the DOM specific implementation. react-router contains all the general routing components:
<Router /><Route /><Redirect />
service_account_prerequisites into metadata, to define the fields that are required in hierarchical orderbuild_prerequisite_options into metadata, to take some data and turn it into a hierarchy of optionsbootstrapGraph method in universal-bootstrap-actions, load the data needed, and use it to build the prerequisite options, then set this into UI state
We want to upgrade to React 16 beacuse it contains quite a few features that will make our frontend code cleaner and faster. The upgrade has been attempted a couple of times in innovation days but it's a fiddly, time intensive task that will need to be scheduled as a cycle goal.
Because React 16 has deprecated some features that other libraries rely on, so those libraries need to be upgraded/replaced/removed. The most common problem we found was other libraries relying on React.PropTypes or React.createClass which have both been fully deprecated in V16.
Most of these libraries can be upgraded quite easily, there are a couple of exceptions: react-router, react-color-picker and enzyme
Our CS team have been getting reports from customers that Geckoboard was crashing the browser window on their TVs after displaying a dashboard loop for a long period of time. I spent a week looking at the issue and found we were leaking memory in at least four places. I figured that sharing my process might help in the future when we inevitably find more leaks.
I knew this was an ongoing issue and that we had investigated memory leaks in dashboard loops before. The first thing I did was to talk to some of our engineers who had worked on the problem previously. I spoke to Mike H and Klara who sent me some Clubhouse cards with detailed user reports.
From what I could tell the leak was happening for:
If every component we built were to go straight into the UI Kit it would become unmanagable. We should be selective about what components deserve their place in the UI Kit. If you're considering adding a component, here are some questions you should ask.
If you've only used a component once it's difficult to foresee how re-usable it is. If this is the case it probably doesn't belong in the UI Kit yet.
Even if you have used a component multiple times in the app, it's possible that your component is so specific to the contexts it's been used that it would be hard for other developers to re-use it. A <Button /> can be used anywhere but an <AddWidgetButtonWithSparkleEffects /> has limited re-use.
So you want to add a component to the UI Kit? Well that's great news. When moving a component from our main codebase into the UI Kit there are a few important things to consider. So that we can maintain a good standard for quality and consistency in the UI Kit it's important that we have a process to follow when adding new components. This is our guide to help make the process as smooth as possible.
Before you get started we've got some rules for checking your component belongs in the UI Kit. Please read and make sure your component qualifies.
Once you've decided that you want to move a component to the UI Kit we have a 10 step guide to moving a compoment into the UI Kit.