README.md in inline_svg-1.1.0 vs README.md in inline_svg-1.2.0
- old
+ new
@@ -40,12 +40,11 @@
object. The
actual path of the file on disk is resolved using
[Sprockets](://github.com/sstephenson/sprockets) (when available), a naive file finder (`/public/assets/...`) or in the case of `IO` objects the SVG data is read from the object.
This means you can pre-process and fingerprint your SVG files like other Rails assets, or choose to find SVG data yourself.
-Here's an example of embedding an SVG document and applying a 'class' attribute in
-HAML:
+Here's an example of embedding an SVG document and applying a 'class' attribute:
```erb
<html>
<head>
<title>Embedded SVG Documents<title>
@@ -229,9 +228,35 @@
```ruby
InlineSvg.configure do |config|
config.asset_file = MyAssetFileLoader
end
```
+
+## Caching all assets at boot time
+
+When your deployment strategy prevents dynamic asset file loading from disk it
+can be helpful to cache all possible SVG assets in memory at application boot
+time. In this case, you can configure the `InlineSvg::CachedAssetFile` to scan
+any number of paths on disks and load all the assets it finds into memory.
+
+For example, in this configuration we load every `*.svg` file found beneath the
+configured paths into memory:
+
+```ruby
+InlineSvg.configure do |config|
+ config.asset_file = InlineSvg::CachedAssetFile.new(
+ paths: [
+ "#{Rails.root}/public/path/to/assets",
+ "#{Rails.root}/public/other/path/to/assets"
+ ],
+ filters: /\.svg/
+ )
+end
+```
+
+**Note:** Paths are read recursively, so think about keeping your SVG assets
+restricted to as few paths as possible, and using the filter option to further
+restrict assets to only those likely to be used by `inline_svg`.
## Contributing
1. Fork it ( [http://github.com/jamesmartin/inline_svg/fork](http://github.com/jamesmartin/inline_svg/fork) )
2. Create your feature branch (`git checkout -b my-new-feature`)