Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async helpers (refactor, externalize, and improve!!!) #28

Open
1 of 10 tasks
doowb opened this issue Jan 18, 2017 · 1 comment
Open
1 of 10 tasks

async helpers (refactor, externalize, and improve!!!) #28

doowb opened this issue Jan 18, 2017 · 1 comment
Labels
Projects

Comments

@doowb
Copy link
Collaborator

doowb commented Jan 18, 2017

@jonschlinkert and I have talked about this and I've been looking through the current modules that have touch points to async helpers and trying some things out to try to improve the experience with some of the use cases that we've come across.

I think that the following steps can be taken to refactor and externalize some of the current pieces, while creating a couple new pieces for so cases:

  • refactor async-helpers

  • remove async-helpers from engine-cache

    • the only real touch points in engine-cache are adding helpers to the asyncHelpers instance when compiling, and resolving async helper ids after the string has been rendered
    • moving this out of engine-cache makes way for the next step
  • base-async-helpers module that adds the async-helpers functionality to base applications

    • move asyncHelper, asyncHelpers, getAsyncHelper, and hasAsyncHelper methods from base-helpers to `base-async-helpers
    • wrap engine-cache methods to inject the async-helpers functionality into .compile and .render (this can be more configurable and only enabled for specific engines)
  • Make built-in singular and plural helpers "smarter" to know if they're being used as async or sync helpers. Either split them out into a module or just check for the callback.

  • base-handlebars-async-helpers module to add necessary helpers and batch methods in Handlebars to allow using async-helpers with built in Handlebars partial syntax.

    • I've done this in an example and tried to implement it directly in engine-handlebars, but engine-handlebars is not able to get a reference to the asyncHelpers instance created by engine-cache.
    • I think splitting out the other pieces and adding this functionality as a plugin will let users choose when they're going to use async-helpers and if they'r using Handlebars, they can also include this module to fix some specific use cases.
    • Since we include engine-handlebars in assemble by default, we can include this also (or have an option to enable async-helpers which would then include base-async-helpers and base-handlebars-async-helpers)
  • optional base-engine-async-helpers module that will do something with engine-base to get async-helpers to work with regular javascript conditional statements (I don't know exactly how to do this yet, but we've thrown around a few ideas)

I'll be working on these changes over the next few days. Feedback is welcome and encouraged!

Repository owner deleted a comment from DanielaValero Jun 26, 2017
@jonschlinkert
Copy link
Owner

deleted a comment that wasn't related to this thread

@jonschlinkert jonschlinkert added this to async-ness in 2.0.0 Jun 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
2.0.0
async-ness
Development

No branches or pull requests

2 participants