You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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 arequire
is present in atemplateConfig
. 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 namedcompontents/dialog-view
which is loaded from a directory (let's say~/Scripts/app
via arequire
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:My template loader would have the task of "overriding" whatever handles
require
so that it could redirect therequire
call to the appropriate directory (~/Templates
) and prepend thetext!
loader to the module name.The issue is this segment of code in knockout:
Before any of the loaders are called, the function that implements the
require
handling (possiblyGetConfigFromAmd
) is called. This essentially prevents any loaders from overriding therequire
functionality in the case that arequire
from atemplateConfig
should be treated differently than a standardrequire
call and something with the samemodule.id
has already been loaded from the default configuredrequire
base path.Again, not a big deal, but if there was some way to override the default
require
handler functionality so that we could handlerequire
calls for the different types of configurations for components (template
,component
,viewModel
) I think that would be awesome.The text was updated successfully, but these errors were encountered: