[discussion] refactor api #32

Activity

1. hughsk commented on Jan 11, 2016

   

   hughsk

   on Jan 11, 2016

   Member

   More actions

   I'm about to go to sleep :) But quickly:

   add support for inline template strings in addition to external files

   This doesn't need to be specific to template strings, you could just do:

   const prefix = sheetify(`
     /* Inline CSS */
   `, { inline: true })

   Then there's no need to depend on ES6 syntax, and you now have one API instead of two 🎉
2. ahdinosaur commented on Jan 11, 2016

   

   ahdinosaur

   on Jan 11, 2016

   Member

   More actions

   so keen, this is exactly where i'd like to go with sheetify. thanks for writing this up @yoshuawuyts. 👍
3. yoshuawuyts commented on Jan 11, 2016

   

   yoshuawuyts

   on Jan 11, 2016

   ContributorAuthor

   More actions

   @hughsk I think that's a reasonable proposal; I agree we should adopt that syntax.

   I'd be happy to see sheetify also support tagged template strings using require('sheetify') (I'm hoping babylon can pick them up), but I reckon that's more of a stretch goal so it's best to focus on the simplest version for now.
4. ahdinosaur commented on Jan 11, 2016

   

   ahdinosaur

   on Jan 11, 2016

   Member

   More actions

   from #16, might want to add the ability to use postcss plugins via the options, as opposed to a separate plugin format (for example, cssnext is now postcss-cssnext).

   an open question is whether we specify any default plugins, such as what css-modulesify does. specifically i'm thinking of postcss-import, perhaps also a way to pass values around (like this but in our own way).
5. yoshuawuyts commented on Jan 12, 2016

   

   yoshuawuyts

   on Jan 12, 2016

   ContributorAuthor

   More actions

   Yeah, I reckon directly consuming postcss plugins would be reasonable, given that we're using it as a parser we might as well go all the way. Despite the postcss plugin format being unnecessarily clunky, his saves us work of creating a compatibility layer. If we're going for simplification we might as well go with it; if for some reason postcss becomes irrelevant in the future we'll deal with a different plugin format then.

   I'm cool with adding postcss-import as it's a good fit for sheetify and the idea of modularity / namespacing.
6. yoshuawuyts commented on Jan 17, 2016

   

   yoshuawuyts

   on Jan 17, 2016

   ContributorAuthor

   More actions

   after talking to @hughsk in person, I have come to agree that using postcss-* style plugins directly isn't a good idea. I think we're all coming here from a "least maintenance needed" perspective, and while hooking into postcss-* might make it easier to interop with that ecosystem, not doing it reduces the the surface of stuff we should potentially care about.

   I'm not sure I'm doing a great job at explaining this, but I hope it makes sense.
7. yoshuawuyts commented on Jan 17, 2016

   

   yoshuawuyts

   on Jan 17, 2016

   ContributorAuthor

   More actions

   I've created separate issues for all todo's mentioned in this thread. I'm sure as we implement it all, new issues will arise. So I'm closing this issue for now as we've resolved this discussion into concrete actionables ✨

   If I've missed anything tho, don't hesitate to reopen.
8. yoshuawuyts

   closed this as completedon Jan 17, 2016