Recent searches


No recent searches

Erik Dunning's Avatar

Erik Dunning

Joined Apr 15, 2021

·

Last activity Dec 15, 2021

Following

0

Followers

0

Total activity

7

Votes

0

Subscriptions

3

ACTIVITY OVERVIEW

Latest activity by Erik Dunning

Erik Dunning commented,

Community commentDiscussion - Zendesk on Suite best practices

Hey Aleksey,

I've documented some information about how the Handlebars partials are used in this GitHub gist:
Modular HC Handlebars Theming

Hopefully this helps!

View comment · Posted Mar 03, 2020 · Erik Dunning

0

Followers

0

Votes

0

Comments


Erik Dunning created a post,

PostDiscussion - Zendesk on Suite best practices

This is the second in a series of posts on the different elements we use in creating and supporting our Help Center customizations. If you haven't read Zendesk theme customization part 1: How we use Zendesk features yet, it's best to start with that post, as this one builds on the first. The goal is to provide enough information that anyone could build similar customizations on their own. These posts are a starting place; we aim to provide more code examples in the future.  

Now let’s examine some open source tools we use to leverage the data and construct modules.

Reusable theme modules and third party modules with Node.js

Documentation: https://nodejs.org

Our Guide theme makes a large number of UI features into self contained modules that:

  1. Promote code reuse and maintainability.
  2. Make it easier to see where the code for a specific feature resides.
  3. Open the door to unit testing for module logic.

Node.js allows us to separate our JavaScript logic into a large set of files that can easily share common utilities and library methods by using require() or import.  Pulling in classes and methods from third party sources is a cinch.

Handlebars & jQuery

Documentation: https://handlebarsjs.com/ & https://jquery.com/

Handlebars and jQuery provide the display and functional layers for our modular theme.  They are well documented and are compatible with the legacy code we still need to support.

The similarity between Handlebars and Curlybars syntax also helps provide a consistent syntax between the server templates and the client side templates.

However, some of our modules are written in a manner that closely resemble the structure of React components (https://reactjs.org/).  We’ll likely be adopting React in the future to use the suite of Zendesk Garden components. See here for more information.

Webpack

Documentation: https://webpack.js.org/

Webpack allows us to process all the module code and package it into just three production-ready files.

Generated scripts

The script files generated by Webpack are modules.js and modules.css.  They comprise all of the transpiled module JavaScript and CSS respectively.

Generated footer

Each of the modules has the option of specifying an arbitrary number of *.hbs files which are concatenated together to form footer.hbs.  Concatenating files together allows us to simulate having an arbitrary number of server templates to better segment our code.  

Gulp

Documentation: https://gulpjs.com/

Some of our routine tasks were greatly simplified by using Gulp to script them.  Some examples include:

  1. Running Webpack
    1. Linting the module code with ESLint (https://eslint.org/)
    2. Transpiling with Babel (https://babeljs.io/)
  2. Concatenating the footer templates with gulp-concat (https://github.com/gulp-community/gulp-concat)
  3. Programmatically generating a theme ZIP file with gulp-zip (https://github.com/sindresorhus/gulp-zip)  

Overview of our theme’s architecture

Next let’s see how these pieces fit together.

Anatomy of a theme module

In this example, you can see our “community-posts” module consists of 4 files:

  1. community-posts.hbs - contains Curlybars template code to be processed on the server side, the result of which will be output to the client’s browser.  This is where dynamic content strings and JSON blobs get dumped for the display modules to use on page load. It gets concatenated with all the other *.hbs files in the other modules to become to the footer.hbs file.
  2. index.js - represents the module code which may take the form of an Node.js module or simple HTML

Posted Mar 19, 2019 · Erik Dunning

0

Followers

10

Votes

3

Comments


Erik Dunning created a post,

PostDiscussion - Zendesk on Suite best practices

This is the first in a series of posts on the different elements we use in creating and supporting our Help Center customizations. The goal is to provide enough information that anyone could build similar customizations on their own. These posts are a starting place; we aim to provide more code examples in the future.  

To start, let’s take a look at some of the Zendesk features we use to manage data for modular theme customizations at Zendesk.

Dynamic content

Documentation: https://developer.zendesk.com/rest_api/docs/support/dynamic_content

Dynamic content allows Support users to configure localized text values that are accessible within Guide. Support users with sufficient privileges may update dynamic content text values at any time and changes will be immediately reflected.  A simple UI value like “Browse common questions” is one such example.

Dynamic content may also be created and updated via the API for automated changes:
https://developer.zendesk.com/rest_api/docs/support/dynamic_content#update-variant

An interesting way to leverage dynamic content is to deliver encoded strings in formats like JSON or Base64, instead of just simple text.  This allows us to supply structured data to the modules. Consider values like:

{“jsonConfigKey”: “An Example Title”}

or

QW4gRXhhbXBsZSBUaXRsZQo=

( Generated with: echo "An Example Title" | base64 -i - )

Our theme strategy uses several values similar to these.  They’re stored as dynamic content and rendered as JavaScript variables or HTML contents within Guide.  Be advised that dumping a lot of information into dynamic content may slow down your user’s Help Center experience, especially if large values need to be decoded with JSON.parse() or atob().

Now let’s take a look at how we access dynamic content in Guide.

Curlybars

Documentation: https://developer.zendesk.com/apps/docs/help-center-templates/introduction

Curlybars is Guide’s server side templating language.  It allows developers to control what HTML and dynamic content is rendered to the browser using in a limited set of supported theme files such as document_head.hbs or article.hbs. It uses syntax similar to the Handlebars templating language, which is frequently used by web apps on the client side, but the two should not be confused.

Dynamic content delivery

All dynamic content items registered in the Support product are accessible within any of the supported Guide theme Curlybars templates.  We utilize the footer.hbs template to output preconfigured JavaScript objects the modules use to build the responsive UI.

Here’s an example within a 

Posted Mar 19, 2019 · Erik Dunning

0

Followers

11

Votes

3

Comments


Erik Dunning created a post,

PostDiscussion - Zendesk on Suite best practices

The Help Centers for the Zendesk Support, Guide, Connect, and Explore products have all been recently updated.  They now use a common theme codebase which renders itself differently using brand detection.

Our motivation for using one theme was multifaceted:

  1. We wanted page features that could be reused across brands.
  2. Our complex new client-side features required a developer-friendly architecture to break them into a set of intelligible parts.
  3. A lot of content needed to be configurable and deployable independent of the theme.

We used several powerful Zendesk features and free open source tools to create this modular theme strategy. We’re excited to share how we did it, and hope it will serve as an example for your Help Center customizations.

  1. How we use Zendesk features
  2. How we use open source tools

Posted Mar 19, 2019 · Erik Dunning

1

Follower

8

Votes

0

Comments