On Thu, Jan 25, 2018 at 11:50 AM, sebb <[email protected]> wrote: > On 25 January 2018 at 16:37, Sam Ruby <[email protected]> wrote: >> On Thu, Jan 25, 2018 at 11:32 AM, sebb <[email protected]> wrote: >>> On 25 January 2018 at 16:20, Sam Ruby <[email protected]> wrote: >>>> On Thu, Jan 25, 2018 at 10:08 AM, <[email protected]> wrote: >>>>> + def appmtime >>>>> + # TODO can this/should this be cached? >>>>> + Wunderbar::Asset.convert("#{settings.views}/app.js.rb").mtime.to_i >>>> >>>> Wunderbar::Asset.convert caches the results. It checks the timestamps >>>> of each of the files that are pulled together to produce the desired >>>> output. >>> >>> Yes. >>> >>> I meant could/should the result of the check be cached? >>> As is done with csstime. >> >> I'm confused: >> >> def cssmtime >> File.mtime('public/stylesheets/app.css').to_i >> end >> def appmtime >> # TODO can this/should this be cached? >> Wunderbar::Asset.convert("#{settings.views}/app.js.rb").mtime.to_i >> end >> >> Where is cssmtime cached? > > Sorry, I was referring to the @cssmtime field used elsewhere in the > code (not in roster)
I'm not aware of any code that caches @cssmtime. Some code computes cssmtime in specific routes and passes it as an instance variable to the view. Other code defines a helper that is called by the view. > Since File.mtime is likely to be very quick, there did not seem to be > a need to cache the result here Agreed. > But convert is more expensive. But convert caches the result to avoid this expense :-) Specifically, look here: https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/render.rb#L13 In particular, the following line: return cached if cached and cached.uptodate? This, in turn makes use of: https://github.com/rubys/ruby2js/blob/master/lib/ruby2js/serializer.rb#L66 - Sam Ruby
