Use UTC in views and basecamp/local_time to convert to users’ local time about casein HOT 5 CLOSED

Hi! What’s some typical caching logic in an admin-area view where this is currently a problem?

from casein.

It’s going to vary based on the individual use case, but let’s say we have Author objects and our casein/authors/_table.html.erb view shows photo thumbnails as well as the count of the number of articles by that author. Looking up the photo and the article count takes some appreciable number of milliseconds when multiplied by 50 or 100 or however many authors we want to display in the table at one time.

In a perfect world, we could just cache the <tr> for each author in casein/authors/_table.html.erb like so:

<table class="table table-striped table-hover table-condensed">
  <thead>...</thead>
  <%= render partial: 'author', collection: authors, cached: true %>
</table>

Only the problem is, we are displaying the author’s created_at and updated_at dates in the user’s local time zone. So if someone from California is the first to populate the cache, then a visitor from New York is going to see these table rows showing created_at times in PDT.

It was fairly easy for us at McSweeney’s to simply add local_time to the Gemfile and replace the times with local_time. Individual Casein users can of course do the same.

Totally up to you whether you want to make this part of Casein’s omakase defaults or not. If you wanted this to be supported out of the box, we could simply modify the template generators to use local_time when creating Casein views of time attributes.

If that sounds helpful to you, happy to whip up a PR! And if not, happy to close this issue and simply go about our business manually tweaking the Casein-generated views in our own app, which is also not a problem!

from casein.

Thanks for the clear explanation of need. I hadn't considered that admin table views would benefit too much from global caching, mostly because of security implications. I totally see that, in many situations, users have the same security level and are viewing the same data, in the same way, and caching can help. But, I'm wondering if explicitly tailoring behavior for caching is a can of worms?

Other thoughts I'm having: Why is local time so special that it should get preferential treatment in the Casein core? (versus other user-specific presentation data in an otherwise shared view.) Does it make the basic code generators more complicated? (I guess not, if it's just a matter of using local_time instead?) And, finally, what about backwards compatibly with users who have customized their generated template code? (I guess it would just work?)

I think most of my concerns are unfounded, right? If you think this is a minor tweak with only benefits, then yeah, let's go ahead and do it! Thanks again for bringing it up!

from casein.

You’re definitely right that going too far to anticipate or cater to specific caching use-cases is a can of worms: as you say, different users might have different permission levels, for one thing.

I don’t think it would make the generators any more complicated, and I don’t think there is a backwards-compatibility issue, but it does introduce a dependency. It’s a very small gem, but there’s a question of how well-maintained it will be going forward.

After thinking more about this, let’s keep it in the back of our minds, and in the meantime just let individual users customize as they need.

I’m going to close for now but I’m happy to revisit this!

from casein.

OK, that makes sense. But, yeah, happy to review if it becomes a more-general problem. Thanks again for documenting the issue!

from casein.