search

juxt / modular

MIT License
128 stars 20 forks source link

Add web resource module that implement get-javascript-paths or get-css-paths #26

Open ordnungswidrig opened 9 years ago

ordnungswidrig commented 9 years ago

I like to be able include a webjar resource like "jquery" and have that component provide a get-javascript-paths function like the ClojureScriptBuilder does. The same would be feasible for css webjars, too.

malcolmsparks commented 9 years ago

That's a great idea. I have a modular.bidi component that brings in web resources from the classpath that I use for bootstrap, react, jquery, etc. but I have to manually add the js paths of course - that's not very cohesive.

ordnungswidrig commented 9 years ago

The same would be great to the LessCompiler. Maybe something like anAssetProviderorResourceProvider` Interface would do it? I'm not sure on the interface if -- like in the case of bootstrap -- a single component might provide different resource types like css and javascript.

Either have a single interface

(AssetProvider
   ;; returns a map of types to uris / uri-paths
  (assets [this]))

;; or
(AssetProvider
   ;; returns list of assets for that type (:js, :css...)
  (assets [this type]))

or have multiple interface for Javascript and Css.

I'm leaning to the former because I cannot see why different asset types would need different interfaces.

The inferfaces above all return a list/map of strings. I don't know if that should be extended to support e.g. different script languages (matching the "type" attribute of the <script> tag). A simple solution for that case is to map different script types to different "asset types", i.e. javascript -> :js, dart -> :dart.

malcolmsparks commented 9 years ago

Yes good point. I hadn't thought about LessCompiler but you're right, it makes perfect sense.

I've never been 100% happy with the JavascriptPaths protocol, it was named that way in a hurry and was when I was playing with the idea that components could/should have multiple protocols. I think the benefits outweigh the trade-offs, because of the cohesion that results. As a name, AssetProvider feels better, and the name matches bidi's new RouteProvider protocol.

Would we end up having a component per webjar? (see webjars.org). That seems painful. I wonder if there's a better way of doing it. I have quite a few JS files I use regularly now (bootstrap, jquery, momentjs, reactjs...)

It would be nice to have a consistent way of indicating a preference for minified or original versions of JS and CSS too.

Anyway, this is a perfect example of the benefit of good component cohesion

I don't think the asset type is that valuable, so I don't think different asset types should have different interfaces and agree with your preference here.

How does the component compose the routes - via bidi's path-for ? That would make the component depend on bidi but I don't see another way.

On 30 March 2015 at 09:04, Philipp Meier notifications@github.com wrote:

The same would be great to the LessCompiler. Maybe something like an AssetProviderorResourceProvider` Interface would do it? I'm not sure on the interface if -- like in the case of bootstrap -- a single component might provide different resource types like css and javascript.

Either have a single interface

(AssetProvider ;; returns a map of types to uris / uri-paths (assets [this])) ;; or (AssetProvider ;; returns list of assets for that type (:js, :css...) (assets [this type]))

or have multiple interface for Javascript and Css.

I'm leaning to the former because I cannot see why different asset types would need different interfaces.

The inferfaces above all return a list/map of strings. I don't know if that should be extended to support e.g. different script languages (matching the "type" attribute of the Githubissues.

  • Githubissues is a development platform for aggregating issues.