Posts
-
Passing Functions as React Props
Originally posted on Code Mentor: https://www.codementor.io/ryan286/passing-functions-as-react-props-9fimj8ikv
I recently had a discussion with a coworker about the naming of a function property that will be passed to a React component. It got me thinking more thoroughly about the role of functions as properties. I find that they usually fall into one of two camps. The function either:
- Notifies the container of user or component action, or
- Provides some capability that the component needs.
-
Squashing Commit Histories
I’ve encountered a couple scenarios in which I wanted to squash the git history of a particular branch.
-
Including Git History in a Jekyll Post
Now that I’ve bought into a Jekyll-based blog running on GitHub Pages, the next step was to surface the revision history for a post at the bottom so readers can easily see when and what was updated.
-
CodePen on Jekyll
As part of getting this blog up and running, I’m sharing a few of the things I’ve set up for others doing the same. This installment is the rather simple CodePen include to embed pens in my posts. I took it a step further to allow including any pen by
hash
andusername
with the latter defaulting to thecodepen_username
value in the site’s_config.yml
. -
Hooks API
Enyo has a pretty deep inheritance heirarcy and one of our areas of research right now is ways to flatten it to improve performance and ease debugging. We’ve discussed increasing our use of mixins (or something similar, perhaps) to add functionality to a kind without defining an entirely new one. Mixins have a couple of drawbacks regarding overriding methods, however:
- You have to use
kind.inherit
which is a bit awkward - It still increases the call stack
One common place for method overrides are the lifecycle methods (e.g.
create()
,destroy()
). In most cases, the mixin does its work either before or after the call to the super without modifying the arguments. To make this a bit easier, I’m proposing a new HookSupport mixin. - You have to use
-
EnyoJS on Cloud9
I've been playing around with the Cloud9 IDE a bit recently to do some remote development. It's come a long way from when I first used it and is quite functional. A great addition is an interactive command line with a git client. So I thought, "It'd be nice to get the EnyoJS bootplate up and running here." Following the general instructions from the wiki, I put together a set of commands that gets everything set up.
TL; DR
Pull in bootplate, update the submodules, and "disconnect" the master branch from the bootplate repo.
-
Using Gravatar with Parse
Gravatar is an service that allows users to specify a public avatar image linked to an email address. I recently decided to allow users to use their Gravatar avatar with my Parse-backed app rather than build in my own avatar system. To simplify things, I’ve hooked beforeSave for the User object to hash the email address and add it to the object. That ensures that any email address change is automatically hashed on the server and allows me to send the hash down to clients rather than the email address to protect privacy.
function MD5(s){ /* one of many publicly available MD5 functions */ } Parse.Cloud.beforeSave(Parse.User, function(request, response) { var email = request.object.get("email"); request.object.set("emailHash", email? MD5(email) : ""); response.success(); });
-
EnyoJS Feature Request: appCache Support
Obviously you can add appCache to existing apps but there are a couple things I think the framework could add here. First, let’s get the appcache events wired into enyo’s event model.
-
Enyo Extensions
I have a couple extensions to Enyo that are in varying degrees of maturity that could use some external feedback and development. Below is a summary of each. If you're using these, something similar, or have some thoughts on where they should go, I'd like to work with you to improve them. Feel free to comment below, catch me on twitter @theryanjduffy or send an email to ryan@tiqtech.com.
-
enyo.RemoteControl
Wanted to share a preview of a new kind I’ve been working on. The idea stemmed from a recent patch I submitted to fix remote loading of js into enyo. A prime use case for that capbility is to deliver a mobile website in which the entire site could be integrated into a single enyo app without loading the entire source on load. Each view could be managed by a parent enyo.Panels and loaded as requested.