Add pretty URL slugs to listing pages

[bencpeters]

Add pretty URL slugs to listing pages

This PR adds descriptive url "slugs" to the end of listing page URLs:

/listing/jsQvgvy6eJy56TNCFfQp8 => /listing/jsQvgvy6eJy56TNCFfQp8/the_triton_55_triton_park_lane_foster_city_ca

The bare "id-only" URLs will still work; they issue an immediate 301 redirect to the pretty version. This PR adds a general purpose Redirect component to accomplish this.

The url slug is available as an attribute urlSlug on the Listing type.

Minor version bump of eslint-typescript to allow function definitions. This was necessary to avoid an eslint error on this line.

Closes #215

[jaredcwhite]

@bencpeters Nice solution! I'm wondering if we even need the guid in the the URL though? The number of available listings isn't that high so certainly no real risk of slug collision.

[bencpeters]

@bencpeters Nice solution! I'm wondering if we even need the guid in the the URL though? The number of available listings isn't that high so certainly no real risk of slug collision.

Personally, I like having the guid in there - it allows us to keep a "stable" URL in cases where the listing name changes (or maybe the address is incomplete/incorrect to start with and gets updated?). I could also see a higher chance of slug collisions in a multi-unit building - maybe the address is the same for all of them if the listing mistakenly doesn't include a unit number?

I don't feel super strongly on it though.

[jaredcwhite]

it allows us to keep a "stable" URL in cases where the listing name changes

That's a good point. Probably wouldn't happen after a listing goes live, but during development I could see that. Maybe we can knock the id length down to 8 characters or something of that nature?

[bencpeters]

That's a good point. Probably wouldn't happen after a listing goes live, but during development I could see that. Maybe we can knock the id length down to 8 characters or something of that nature?

Ya, that seems reasonable. Where are those IDs generated right now? I just saw them listed in the JSON data files?

[jaredcwhite]

Now that you mention it, they are totally arbitrary (hard-coded into the JSON). So perhaps we can file that as a separate issue related to the future Listings service.

[bk3c]

FWIW, I'd definitely be in favor of shorter nanoids. Perhaps 8 characters, which should give us a 1% chance of collision every ~239 years if we generate 1/hr? I'm open to other lengths, though.