I have a front-end project laid out like so:
resources/assets/js
resources/assets/jade
resources/assets/svg
resources/assets/sass
I have recently found out that it is possible to define aliases in webpack to prevent the constant use of relative paths like ../../../.. by providing them in the resolve.alias map. Now my imports in Javascript are much simpler to understand. However, I've tried doing something similar for my Jade templates, defined like this:
<template lang="jade">
include ../../../jade/pages/home
.component-class
+home-item
</template>
Instead of writing ../../../jade/pages/home, I'd like to write pages/home but can't see any documented way of doing so. Is this possible? This is something I'd like to do with sass-loader as well.
Yes, you can definitely do this. I wish the docs were more clear about this as it's pretty important for a large pug app.
Add this to your app.js/server.js:
app.locals.basedir = path.join(__dirname, 'views');
Then you can reference all template files using a leading backslash character, for example:
include /pages/administrator/home
include /mixins/widget
Related
In NuxtJS (vuejs framework), I am having some difficulty with routes, I wanted to ask how we can create this kind of route using pages directory or any other approach?
Example:
Sample routes:
/some-route-of-page-2021
/some-route-of-page-2022 and so on for every year.
2021/2021 is the year and that will be dynamic
Having a dynamic variable inside of a path itself is supported in Nuxt3 . In Nuxt2, you can only have /some-route-of-page/XXX. In this case, it seems a bit more logical to have this kind of structure anyway. Usually, you don't have a lot of variables interpolated in the path itself, can be kinda confusing IMO.
Dynamic Pages are handled by adding an underscore in front of the parameter. For example "_pageyear.vue"
Docs: https://nuxtjs.org/examples/routing/dynamic-pages/
Sandbox: https://codesandbox.io/s/github/nuxtlabs/examples/tree/master/routing/dynamic-pages?from-embed
Most of what I use javascript for is d3 and the rest of my javascript knowledge was self learned by looking at examples, reading docs, etc. The point is my "in-depth" knowledge of javascript is not so deep...
Since I mostly work with d3 I have written a lot of my own functions and closures (as suggested by Bostock in Towards Reusable Charts) which build on top of d3.
To keep track of all the code I have written them in separate files and to use my collection I have tried a few ways such as dynamically appending script tags to the head of the document, concatenating files, etc
Ideally, I should make proper module of my code and bundle it together.
So I have set off on that path and stumbled across rollup and this tutorial by Lengstrof.
I tried following it and got it to work with some minor changes (e.g. it assumes babel-core is already installed and currently there is an issue with postcss.
Anyway, I made a small repo to demonstrate my use case (project repo). It has some modules which includes helper functions, some prototypes, and some closures.
Ideally, these would all be exported into a closure / object just like d3 (e.g. myClos) where I could then call any of the functions I have written.
Unfortunately, I have no idea how to do this and did not find relevant examples / tutorials on how to do this. Also, in doing this, would I have to then call my helper functions like myClos.helper1().
Anyway, I would greatly appreciate your help. The ideal end would be to have the rolled-up file myclos.min.js work like d3 where I include the script tag and then myclos is in the global-namespace.
Many thanks in advance for you assistance.
Make sure you're following the appropriate format for importing/referencing your external helpers/modules (e.g., from your main file: (esmodules) import foo from './helper1'; console.log(foo.helper1()) or (commonjs) const foo = require('./helper1'); console.log(foo.helper1()).) In the module you're trying to export from (helper1): (esm) export default helper1, (cjs) module.exports = helper1. The Rollup docs have good examples of this.
I'd bet this question is already answered somewhere, but I'm coming up empty.
I'm using Angular 1.5.7 and wanting to import some external HTML, within my project, into a component controller (to use in a tooltip), and I can't figure out how to do it.
My structure within a folder is simply like this:
component.js
component_template.html
other_html.html
I've tried the following, using WebPack with the html and ngTemplate loaders (configured in my webpack config): Above my controller declaration, I add
import other_html from './other_html.html';
which is exactly how I get the template for the view (and which works with no further ado):
import component_template from './component_template.html';
angular.module(module).component('name', {templateUrl: component_template}, ...);
Inside the component controller, I've tried various combinations of $sce.trustAsUrl, $sce.getTrustedHtml, and $sce.getTrustedUrl to unwrap the content of my external HTML (in the variable 'other_html') as a string, but frankly these things just confuse me and the documentation doesn't help. It also seems that I'll need to compile the resulting string against the scope of my controller, but I need an HTML string first (I keep ending up with a URL string).
Can anyone demonstrate for me the best way of doing this, with or without relying on WebPack and the html and ngTemplate loaders in the process?
Thanks
Answering my own question. Not entirely my perfect solution, because I'm not compiling any values from my imported HTML, so I'm breaking it up to control as smaller fragments.
First off, I shouldn't have been using ngTemplate in the mix for this purpose. Secondly, the way around that is to prefix your loader chain with an exclamation point, to override the default from your webpack config.
So, this works to provide me with the string I need:
var other_template = require('!html!./other_template.html');
Since I'm using the string to populate a tooltip (jQuery tipso with a wrapping directive) and requires values only available in my component's $onInit callback, I don't think I even have the chance to compile it against my scope before it ends up as output. But in other cases, I'm sure I could compile it and have things work as expected.
Hope maybe this helps others.
I was wondering if there was any particular naming convention for partials in Stylus.
So, for example, in SASS you might have something like: #import "headers/_default-header.scss" or something to that effect. A partial denotes that a) it should not be compiled as its own and b) it is meant as a dependency for another file.
However, in Stylus there doesn't seem to be any particular naming convention for this. Is there any that are de facto standard or should I stick with just naming them similarly to all other files, despite potential confusion?
Good question :) It looks like people are using it like sass. Using prefix underscore for partial and hyphen for splitting words just like your example _default-header.styl
I'm using underscore template engine for an backbone application. As of now I have over 15 templates in the <head>. Its getting hard to maintain. So far, most of the solutions I seen to manage templates ended up needing them to be js files. That's also a headache, I prefer them to be html files for editing purposes.
I took a look at requirejs and not sure if I need that since it kinda revolves around a more modular approach that I can't say I'm using at the moment (although I will soon).
What will be the best way to manage templates and load/cache them as needed?
Personally we needed a robust solution at my company, so we went with:
Require.js - for module loading
Handlebars - for more powerful templating than Underscore can offer
HBS - an excellent require plug-in from Alex Sexton that handles bringing compiled templates in via Require
With this setup I can keep all of my templates in their own file, and then to use them I have files like this:
define(['template!path/to/someTemplate'], function(someTemplate) {
var MyNewView = BaseView.extend({template: someTemplate});
$('body').append(new MyNewView().render().el);
}
(and as you might guess we have a base Backbone view called BaseView which uses the view's template property to render the view).
Now, all that being said, if you don't need such a robust setup then Require may not be for you. In that case I would do the following:
Put all of your templates in to one or more HTML files; wrap them in script tags, like so:
<script id="dummyTemplate" type='text/template'>
<span>I'm a template!</span>
</script>
Write some code on your server-side to include those HTML files in the main HTML file you send to the client
Write a function which takes a template ID, gets the text of that element, compiles it in to a template, and returns that template (maybe cache the compiled templates if you want ... of course, with Underscore templates I don't think you even need compiling, so you can skip all that).
Use your function to access your templates: $("#something").html(templateFunc('dummyTemplate').template())
This will allow you to store your templates in html files (for syntax coloring), but still access them conveniently in JS. You can also divide your templates between as many files as you want, as long as you can write include logic to bring them in.
If you do opt for Require though, definitely check out the HBS plugin. And if you haven't looked at Handlebars templates yet, you might want to; they're far more powerful than Underscore ones (but like any good templating system, don't allow for too much logic).
Not sure what you mean by it being unmaintainable. Is it just a long list?
You don't need to keep your templates in the head. They can be at the bottom of your body as well. They just need to be defined before you try to use them.
One thing you might look into, depending on the server technology you are using would be to separate your templates into a different HTML file and include it at runtime.