Set preferredPlace based on locality from locale. Implements #89

[viatrix]

Intl.locale is available in Node.js since 13.0.0. I used polyfill for Intl, it will not be necessary after upgrade to a later version of Node.js. Tested on Node.js 12.13.0 and 13.11.0.
(Intl.locale could also be used in util.localeOpts).
Also, code and admin_level are not indexed in db now. Would it be better to add index for it?

[kueda]

@viatrix can you please commit your changes to package-log.json?

[viatrix]

I'll merge recent updates of base repo with api-v2 and update the PR

[kueda]

If you're trying to get your branch up to date, you should pull from the main branch. The api-v2 is currently behind main so it shouldn't have anything that's not already in main.

[kueda]

Great, this is looking good to me. @pleary do you want to take a look to make sure this is working the way you were thinking when you wrote up #89?

[pleary]

Hi @viatrix - sorry I've let this sit for so long. This mostly looks great. I have a few things I'd want to change which might be easier to explain in code, so I'm wondering if you mind if I merge in this pull request then make a commit with some small changes?

One thing is req.userSession.locale isn't available in the lookupPreferredPlaceMiddleware middle because it hasn't been loaded yet. User session details get loaded later in preloadAndProcess. So one change I made is to extract some of the logic in lookupPreferredPlaceMiddleware into a shared method, which will get called in lookupPreferredPlaceMiddleware for the locale param, and we can implement it later for the user after the session is populated. But I actually don't think we need to, so we can stay consistent with the behavior of the website.

The only other change is to use squel when generating DB queries in the Place model. I've set a bad example by breaking this rule myself in the model, and have updated the model to use squel exclusively.

I don't think we'll hit issues with indices on the place model. admin_level does have an index on it, and unless we see performance problems I'd hold off on adding an additional dual-column index with code.

Thanks for your work on this!