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

Default require loading not able to be overridden completely with custom component loader #1647

Closed
kcuzner opened this issue Dec 9, 2014 · 2 comments

Comments

@kcuzner
Copy link

kcuzner commented Dec 9, 2014

This is a very specific use-case and is just something I came across. It is not breaking nor is it particularly important. I just thought I would mention it as a note on a potential future feature. I'm restructuring things to work around it for now.

I am attempting to implement a specific feature that calls for override the default component loading require functionality. I was doing this by writing a new component loader which looks to see if a require is present in a templateConfig. My templates for each component are present as HTML files under a different directory, but with the same module name as the component that required them. For example, I have a component named compontents/dialog-view which is loaded from a directory (let's say ~/Scripts/app via a require call). The corresponding template is located in a different directory (~/Templates for example), but with the same name: components/dialog-view. In order to keep the actual modules from needing to know where exactly the templates are stored, my component configuration that I return in the component module is as follows:

return {
    template: { require: module.id },
    viewModel: MyViewModel
};

My template loader would have the task of "overriding" whatever handles require so that it could redirect the require call to the appropriate directory (~/Templates) and prepend the text! loader to the module name.

The issue is this segment of code in knockout:

if (templateConfig) {
    possiblyGetConfigFromAmd(errorCallback, templateConfig, function(loadedConfig) {
        ko.components._getFirstResultFromLoaders('loadTemplate', [componentName, loadedConfig], function(resolvedTemplate) {
            result['template'] = resolvedTemplate;
            tryIssueCallback();
        });
    });
} else {
    tryIssueCallback();
}

Before any of the loaders are called, the function that implements the require handling (possiblyGetConfigFromAmd) is called. This essentially prevents any loaders from overriding the require functionality in the case that a require from a templateConfig should be treated differently than a standard require call and something with the same module.id has already been loaded from the default configured require base path.

Again, not a big deal, but if there was some way to override the default require handler functionality so that we could handle require calls for the different types of configurations for components (template, component, viewModel) I think that would be awesome.

@carlosagsmendes
Copy link

@kcuzner I was able to override the loading behaviour completely (I'm using System.js as a component loader) by implementing the loadComponent

Here's a working solution:
http://stackoverflow.com/questions/28704885/knockout-components-custom-component-loaders

@SteveSanderson
Copy link
Contributor

Interesting requirement. I see what you are aiming for, though TBH I don't think I'd go with patching require just temporarily while a component is loading. That sounds like it could lead to all kinds of intermittent race-condition bugs. (Or am I misinterpreting the proposal?)

Could you instead wrap window.require globally, independently of KO components? Then you can put in your own logic to recognise some custom module ID format and translate that into whatever actual require.js/otherloader module ID format will cause it to get loaded from the correct place.

Closing as this seems outside the scope of KO, but please reopen if you disagree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants