javacript posts

Went to a refresh cleveland event tonight, ReactJS: A hands on introduction. We…

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.

Troubles

We have made use of the window in a few sites so far, and the grid on alpleaders.org. 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.

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.

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.

At work I did my first fully ajax loaded, from scratch site, Block Bros. I used jQuery with my own library of "wrapper" classes for loading the ajax and animations between "pages". I had to write a lot of new stuff though and modify some of my library classes to get everything working smoothly.