javacript posts

Went to a refresh cleveland event tonight, ReactJS: A hands on introduction. We worked on a simple contact list application tutorial created by the speaker. It was a nice simple introduction to React JS and ES6. I paired with someone, and we made it about halfway through. I will have to look at it in more depth later.

React JS is a view library for javascript that uses virtual DOM diffing with the real DOM to increase rendering performance. It also uses JSX to combine templates with view controller logic. I have been interested in it for a while but never really played with it where I got to actually use it. This was in part because I was most interested in server-side rendering with it and couldn’t get that to work, and because it requires some transpiling to use it in browsers when using JSX.

This was also my first time really using ES6. I’ve been reading a lot about it. Some of it looks interesting, but it also requires transpiling to work in many browsers. Some of it can be cool, but also foreign and hard to parse for someone new to it. I’ve thought it would be cool to write in ES6, transpile to ES5 and ES3, and then use mustard cutting to determine which to serve. It’s hard to figure out how to transpile to ES3 though, and that would significantly complicate my workflow. It doesn’t seem to offer quite enough to be worth it for me.

Kendo UI

We recently acquired licenses for Kendo UI at Cogneato. We have plans to use some of its widgets, most notably the data grid and window, heavily in the admin interface for the new CMS we will be building. We figured that the time we save from not having to build similar widgets ourselves would be well worth the hefty license costs.


We have made use of the window in a few sites so far, and the grid on I have found that for both widgets, it has helped to build a sort of wrapper around them. The wrapper helps normalize configuration and handles some things that we want to happen for all instances. Some of this was related to problems we ran into with the widgets or features we wanted that weren’t built in.

For instance, the data grid has the ability to be filtered per column client side. A ‘row’ mode provides an input with autocomplete for the values in that column. If you want to use a different mode, however, there is no built in autocomplete feature. You have to create an autocomplete widget for each column. Attaching the same data source as the grid uses results in the same number of items in the autocomplete as there are rows in the grid, meaning if 30 items have a ‘State’ of ‘Ohio’, the autocomplete will show ‘Ohio’ 30 times. I set up a helper to build columns and automatically create a new data source with a single instance of each value for the items in a given column. I’m not sure why, since they already built their own logic for the ‘row’ mode, they couldn’t make that an option for other modes.

Continue reading post "Kendo UI"

Backbone: Maintain scroll position when going back

I’ve been spending a lot of time at work recently working on another phone app. Like our other apps, we’re using Phone Gap to build an app with web technologies. Like one previous app, we’re using Backbone, adding Marionette to help this time. Backbone apps are generally SPA‘s that rerender entire pieces of the HTML document when the underlying data changes. This can often be basically the entire content of the document when you change routes.

Because there is no page change, browers don’t typically change the scroll position when you visit a new “page”. So when you click a link at the bottom of one page, you may end up at the bottom of the new page you are loading. It’s common to have apps set the scroll position to the top via JavaScript on page change, like window.scrollTo(0, 0);.

What happens when hitting the back button varies from browser to browser. Some, like Chrome, try to remember the scroll position for each fragment identifier (how Backbone handles routes by default), while others, such as Safari, do not. When they do not, it can be a usability problem working with lists of items. You might visit the detail page of one item by pressing a link in the list, then go back to the previous page wanting to look at the next one, only to find your place is lost.

Continue reading post "Backbone: Maintain scroll position when going back"

Responsive Behavior

Styles (ie CSS) are the primary focus when it comes to making a site responsive, but the behavior (ie JavaScript) must also be able to react differently to different circumstances. A site might have a horizontal navigation with drop-down menus for wider viewports, but a simple vertical slide open and closed navigation for narrow viewports. The site must not only be able to change the styles that make those menus look right but also the script that drives the behavior. Some behavior might even need to manipulate that DOM to function properly, such as sliding banners with inserted navigation. The DOM will need to be changed one way for certain viewport sizes and those changes reverted, and possibly other changes made, when switching to different viewport sizes.

One might contend that most viewers won’t be switching their viewport dimensions, but window resizing does happen, text can be resized (for ’em’ breakpoints), and mobile devices can be rotated. The site should not break when this happens. Also, even without changes, the correct behavior must be run.

For dealing with this, I have created a ResponsiveHandler class that listens for resizing of the window and fires an event when changing breakpoints. For each behavior that needs it, I listen for this event and run the appropriate construction and destruction depending on what the new and old breakpoints are/were. Behaviors can also simply use the class to determine which breakpoint the site is currently in and act accordingly.

Continue reading post "Responsive Behavior"