Hackathon

Style Dictionary Hackathon

Schedule

• 9:00 - 10:00 Guests arrive, get bagels and coffee, introductions
• 10:00 - 10:30 Overview on Style Dictionary, where it is at, how the day will be structured, QA
• 10:30 - 12:00 Get started on projects
• 12:00 - 1:00 Pizza
• 1:00 - 3:30 Work on projects
• 3:30 - 4:00 Beer with the office
• 4:00 -  Demo any work, finish up, hang out

Projects

• New Features
  • Add custom parser support. User should be able to supply a custom parser to the style dictionary to be used when reading property files. It should be done in a generic way so that any parser (yaml, hjson, and any other) could conceivably be used. A parser should be a function that takes a file (as a path string) as input, and outputs a JS object. Any function that follows this could be used as a parser. #85 (https://github.com/amzn/style-dictionary/issues/85)
  • Clean up filter support in templates and formats. Default templates and formats have varying support for a filter, which filters which properties to output in the file. We should define a standard way to filter properties and use across default templates and formats. #86 (https://github.com/amzn/style-dictionary/issues/86)
  • Add nested/flat formats and templates. Right now the default formats and templates make some assumptions about the format of the output. Because a style dictionary internally has both a nested object structure as well as a flat array structure of properties sometimes #58 (https://github.com/amzn/style-dictionary/issues/58)
  • Add asynchronous support for actions and callback after build. Right now actions can be asynchronous or synchronous depending on how you write your code. An action could fire asynchronous code to a child process, but we have no way of knowing when it finishes. We might also want to change the 'platforms' attribute in the config file to an array so that we can ensure the order of building of platforms, but also make sure to not break backwards compatibility and allow for it to be an object or array. #51 (https://github.com/amzn/style-dictionary/issues/51)
  • *Add an import system. *The capability to import and parse existing style files into a style dictionary would enable many teams which are too far along in their existing product development to be able to use Style Dictionary.
  • *Build an editor. *Style Dictionary's goals of single-source-of-truth and style consistency across multiple deliverables right now requires technological background - knowledge of JSON and naming best practices. If Style Dictionaries were editable by non-technical users using a GUI interface, it would be a step towards a separation of concerns.
  • Some feature we haven't thought of yet!
• Demos
  • Clean up demo used in video to get ready to publish. The code right now is in a private repository, ask and I can give you access to it: https://github.com/dbanksdesign/StyleDictionaryDemo
  • Build a Sketch, UXPin, Figma, Adobe XD, or DSM demo using Style Dictionary. See if you can hook up Style Dictionary to either export files for those design tools, import them, or both! I've started on a custom action that exports sketch files based on a sketch file used as a template. It is in a private repo, let me know if you want access to it: https://github.com/dbanksdesign/sketch-style-dictionary
  • Build a Style Dictionary for an existing open source UI framework/design system like Bootstrap, Foundation, Material, etc. Building an example Style Dictionary project from an existing system can make it easier to
  • Build an example that fits into the Android build/dependency ecosystem. We don't yet have a good way like Cocoapods or npm to include a style dictionary as a dependency for an Android codebase. Let's look into how to best hook up to Android projects.
  • Build a Swift example. All the demo code and default templates so far for iOS are Objective-C. Swift is the future, so lets build some swift templates and a Swift example app.
  • *Build a style guide. *One of the main requests / expectations users have of Style Dictionary is that there is an easy / built in mechanism for generating a style guide. Lets see if we can build a first run at a Style Guide. (this has already been partially started as mentioned in the demo video (first bullet point in this Demos section).
• Projects Using Style Dictionary
  • Start a new project using Style Dictionary. Suggest improvements to documentation around getting started. Ask questions that come up.
  • Work on your existing Style Dictionary project. Ask questions, suggest improvements, find bugs.