Posts tagged code
– page 3

Apologies for the title. It’s groan worthy and, I assume, has been done many times before but once it was in my head I couldn’t get it out. As penance, please accept the Vue Inner Image Zoom open source component.

I spend most of my time writing React so I thought it might be fun to give Vue.js a try. As a starter project, I decided to rewrite the React Inner Image Zoom component and accompanying demo pages using Vue. All of the functionality is the same, zoom with drag to explore on mobile and dragging or hover panning on desktop. Optional fullscreen on mobile and responsive image support. Since Vue isn’t my first language, if you use it and notice any egregious best practices missteps please let me know.

Installation details are available at NPM or Github. Demos are here.

And if you’re wondering what I thought of Vue, here are a few observations:

• It’s pretty easy to learn the basics. The new syntax took a little getting used to but it didn’t take too long to port over a component.
• I really like Vue CLI and how easy it is to customize things like linting and testing.
• One thing I missed was built in portal support (but it sounds like that might be included in the next version!).
• For some reason my biggest sticking point was figuring out how to render code snippets as strings. It turned out to be fairly simple but it took me forever to even Google the right terms.

I don’t know about everybody else but my productivity technique during the coronavirus lockdown has been to start a ton of projects, get antsy in the middle, and then abandon them for something new. And also, despite a very low bar, to somehow post on here even less than before.

Now that we’re somewhere between five months and five years into this (time has no meaning anymore), it feels like maybe I should try following through on some of this stuff. As a small step in that direction, I just published an update to my react-inner-image-zoom package.

Version 1.1.1 includes a new drag option for moving zoomed images on non-touch devices (based on a user request!) plus minor styling and dependency updates. The demo and code example are here.

Hopefully checking one item off my list will get me moving on my other half-finished odds and ends.

In a previous post, I went over my process trying to develop a PostCSS plugin to make updating custom CSS for Google AMP easier. That plugin seems to be working okay (yay!) but since it’s not integrated into my Webpack build, there’s still a lot of manual work to be done and room for human error. 

So the next step was clearly to jump into learning Webpack plugins. I needed a plugin that could watch for CSS files created using the MiniCssExtractPlugin, filter out all the unnecessary styles, and create a new file just for AMP. The results are on GitHub. 

My build process is pretty simple so it’s very likely there are options or interactions I haven’t thought of. If you end up using it and notice any problems, let me know!   

I have mixed feelings about AMP but supporting it seems like the only way to get any traction in Google searches for my fonts so here we are.

When I was updating my site less frequently, manually copying and pasting the stylesheets and cleaning them up for AMP seemed perfectly reasonable. Lately though, I’ve been trying out new designs more often and it’s been too easy to accidentally forget and let the pages get out of sync. So I decided to try creating a PostCSS plugin to automate the process.

Thinking about the changes I was making by hand, I knew I wanted my plugin to filter out:

• Media queries for desktop breakpoints
• Non -webkit- vendor prefixes
• Specific block names or other prefixes (for BEM or other namespacing)

• !important flags
• -amp classes or i-amp tags

The PostCSS guidelines are pretty clear that a plugin should “do one thing, and do it well” and provide some examples using monorepos to handle more complex tasks. I’ve been meaning to work more with Lerna so this seemed like a good excuse. 

The result is the postcss-amplify plugin. You can check out Github for instructions on how to use it with your current PostCSS setup or I made a web interface for quick use. If you try it and notice anything weird, let me know in the comments or by submitting an issue. I think my next step will be to create a Webpack plugin to fully automate my build so keep an eye out for that.

Apologies if you were hoping for a font related post but I just released my first open source React component on NPM so I’m pretty excited about that right now.

Maybe it’s because I’ve done a lot of e-commerce work but it feels like I’ve had to implement the same product image zoom in multiple occasions. This jQuery Zoom plugin sufficed for a while but it usually required some retooling for mobile devices and didn’t feel right in an otherwise React environment. Not to mention the issues that cropped up when the designs called for image zooming inside a carousel (which was surprisingly often). So I tried to take that zoom and pan functionality and move it over into a React component that works nicely with other React modules. 

React Inner Image Zoom includes:

• Default zoom on click + pan on hover behavior
• Zoom on click + drag on move on touch devices
• Support for responsive images
• Optional fullscreen zooming at smaller breakpoints on touch devices
• Out of the box integration with other React components like react-lazyload and react-slick

I just published my first NPM package!

It’s a fairly simple module to add a height based JavaScript fallback for -webkit-line-clamp on browsers that don’t support it (i.e., Firefox and IE). I came across a case at work where we needed cross-browser line clamping with different line counts depending on the breakpoint and with consistent rendering even with web fonts on mobile devices. We tried a few existing JS truncation libraries but sometimes you want the CSS to do the heavy lifting.

The module is called Clamps (because my names are often Futurama inspired) and you can check it out on NPM or Github.

Hit me up with all your issues; they’re still new and exciting to me!

Generally when I post about programming it’s because I’ve finally found a solution to something that has been driving me crazy, some problem with a lot of documentation to read through and not a lot of Stack Overflow answers (and if they do exists, the use case is always a little off). This is no exception!

First, why would you want to combine React and Ruby gems? In my case, I thought it was the simple, lazy path. Way back when, the site I work for was built using will_paginate for all pagination. I recently ran into a case where I needed to include that pagination in a React app. It wasn’t for anything fancy, the links and logic needed to match the rest of site. So, trying to re-create the gem magic in React seemed like overkill compared to creating a partial with the code, generating an HTML string using the Rails render_to_string method, and sending it to React to dangerouslySetInnerHTML.

Well, it turns out will_paginate uses the url_for method and it was not happy to be called without the request data (undefined method `host’ for nil:NilClass?!) it uses to build urls. After a lot of hunting around, I came across this pull request to get will_paginate working with mountable engines that seemed adaptable. My helper accepts the request from the controller and pulls out the necessary fields to send with it’s own instance of url_for. 

module WillPaginateHelper
  class StringLinkRenderer < WillPaginate::ActionView::LinkRenderer
    protected

    def url(page)
      @base_url_params ||= begin
        url_params = merge_get_params(default_url_params)
        url_params[:only_path] = true
        merge_optional_params(url_params)
      end

      url_params = @base_url_params.dup
      add_current_page_param(url_params, page)

      if @options[:url_builder]
        @options[:url_builder].call(url_params)
      else
        @template.url_for(url_params)
      end
    end
  end

  def will_paginate_string(collection = nil, options = {}, request = nil)
    params = {
      :host => request[:host],
      :controller => request[:controller],
      :action => request[:action]
    }

    unless request.query_parameters.empty?
      request.query_parameters.each do |k, v|
        params[k] = v
      end
    end

    options.merge!(
      :renderer => WillPaginateHelper::StringLinkRenderer,
      :url_builder => ->(params) { Rails.application.routes.url_for(params) },
      :params => params
    )

    will_paginate(collection, options)
  end
end

(GitHub Gist)

Then, in the partial that is being rendered to a string, it’s possible to call will_paginate_string(collection, options, request) and the results can be sent as a JSON response to render in React.

Admittedly, Rails isn’t my strong suit so I’d be interested to hear if I missed some easier way to do this.