Comments (6)
From looking at the code it does look like the taglib loading relies on a path to json file. I'll investigate making changes to allow loading a taglib from object in memory.
from marko.
Thank you, @philidem!
Looking forward to use this feature in my project.
from marko.
Just to elaborate on @philidem comments (and this may be more information than you need), we only want to support declarative registration of custom tags for the following reasons:
- Tags need to be discovered at compile time (the templates compile differently based on the set of known tags) and the tags need to be available at runtime (which may be on the server or the client) and it would be awkward to have to register custom tags in both places.
- The
markoc
command line compiler should to be able to compile templates without running any user JS code (that is tags need to be discovered based on a declarative mechanism) - There is no single lookup for all tags and custom tags are discovered relative to a template's location on disk. Among other things, this allows installed modules to have their own custom tags that would not pollute the parent application.
- Templates are compiled such that custom tag renderers are
require
'd and this allows client-side JavaScript module bundlers to automatically include only the tags that are needed by a compiled template module
I can't think of any reason that you would need to programmatically register new tags at runtime, but if you share more details about your use case then maybe I can offer better help.
Thanks for the feedback. Let us know if you have any more questions.
from marko.
Also, if you have ideas on how we can improve how tags are registered then please feel free to share, but there is a requirement that it needs to be declarative (for the reasons above).
from marko.
I did investigate this and I came to the same conclusion as Patrick. I think it would have technically been possible to support the definition of tags through a code change but this goes in the opposite direction of modularizing tags and the components that use them. The discovery mechanism for finding tags is an important feature of Marko that allows tags/components to be shared without having to require users to manually register tags. For this reason, I would discourage manually registering tags and instead rely on the discovery of tags from marko-taglib.json
and marko-tag.json
files. I would also like to know if relying on these files prevents your project from using Marko effectively.
from marko.
I agree with you, this is right decision in this case.
But in my situation I need to integrate Marko into my framework. It means I need to register some module-wrappers as custom tags and it is needed to do before calling compile
method.
Actually, this is not a big problem for me because I have simplified stream-based HTML parser for using these module-wrappers as custom tags. I just wanted to remove my implementation and replace it with Marko functionality.
Thank you, anyway.
from marko.
Related Issues (20)
- Bug: broken link in CONTRIBUTING.md HOT 1
- bug: no such script in packages.json HOT 1
- try catch not supported when rendering
- error when rendering with $!{} in .marko file HOT 3
- Typescript: add missing directives
- TypeScript: add event handlers like `onclick` to native tags, with type `AttrString`
- TypeScript: Passing Attributes to Body Content Will Loose Type HOT 3
- Webpack error on Marko versions greater than 5.31.0 HOT 5
- Deprecation warnings in Chrome HOT 5
- `onInput` is not running when it is used in `component-browser.ts` HOT 1
- Static functions or arrow functions do not work on components without a class statement
- How does routing work? HOT 2
- Marko not properly tracking dependency updates in some situations when using the tags-api
- `Marko is not defined` when index.marko imports module from component.ts
- Cannot break generic parameter declarations into multiple lines HOT 3
- Specify Node Engine Constraint in package.json
- Removing a class attribute results in a "null" class HOT 5
- Out-of-order HTML streaming without JS using Declarative Shadow DOM HOT 15
- Uncaught DOMException on Marko 5.33.14 HOT 15
- Difference in dev/production builds
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from marko.