Dry is superset of the Liquid templating language, with first-class support for advanced inheritance features, and more.
Please consider following this project's author, Jon Schlinkert, and consider starring the project to show your
Install with npm (requires Node.js >=14):
$ npm install --save dry
The simplest way to get started is with the render
method, which takes a template string and a data object (the "context").
const { render } = require('dry'); // render is async
console.log(await render('Hello, {{ name }}!', { name: 'Brian' })); //=> Hello, Brian!
Using the code above, you can do almost everything you need to do with Dry.
Tags, Filters, Variables, and more!
See the docs for Shopify's Liquid to learn about all of the features in the Liquid templating language. If you can do it with Liquid, you should be able to do it with Dry. (and if you can't do it with Dry, it's a bug, and we kindly ask that you please create an issue, thanks!)
Docs are on the way. In the meantime, you can use this Liquid docs to learn about all language features, and use the code snippet above to render your templates!
First things first
I'm back! I know I haven't been around a lot lately, but all of that is about to change! Thank you to @doowb all of my sponsors and friends on GitHub who have provided the encouragement and support I needed to begin making this comeback.
Please consider following me and this repository to receive updates, and consider contributing to Dry so we can make this the most powerful templating library in Node.js!
Why Dry? Aren't React and Vue the future?
Yes, yes they are. Dry doesn't compete with them. We use Dry the same way Shopify and Jekyll use Liquid, many end-users don't know how to write JavaScript, and many developers would prefer not to write JavaScript - I love writing JavaScript, and I enjoy Vue and React, but there is something satisfying about deploying a site in 5 minutes using plain text html templates. We also use Dry to design and render email templates, configuration-based system messages, and so on.
What's different about Dry?
Dry is A Superset of Shopify's Liquid with first-class support for template inheritance (ahem... so you don't have to repeat yourself. So it's "dry". I know... it's all I have at the moment).
Highlights of this PR
{% from 'fields' import input as input_field, textarea %}
Lots more!
The tags with leading +
were added to Dry:
(We'll be adding more tags soon! Like section
and other tags used by Shopify)
+Apply
Assign
+Block
Break
Capture
Case
Comment
+Content
Continue
Cycle
Decrement
Echo
+Embed
+Extends
For
+From
If
Ifchanged
+Import
Include
Increment
+Layout
Liquid
+Macro
+Paginate
Raw
Render
+Set
+Switch
TableRow
Unless
+Verbatim
+With
Pull requests and stars are always welcome. For bugs and feature requests, please create an issue.
Please read the contributing guide for advice on opening issues, pull requests, and coding standards.
Running and reviewing unit tests is a great way to get familiarized with a library and its API. You can install dependencies and run tests with the following command:
$ npm install && npm test
(This project's readme.md is generated by verb, please don't edit the readme directly. Any changes to the readme must be made in the .verb.md readme template.)
To generate the readme, run the following command:
$ npm install -g verbose/verb#dev verb-generate-readme && verb
Jon Schlinkert
Copyright © 2021, Jon Schlinkert.Released under the MIT License.
This file was generated by verb-generate-readme, v0.8.0, on July 20, 2021.
定义 不要重复自己 注意:重复的代码不一定违反DRY原则,不重复的代码也有可能违反DRY原则 三种典型场景 代码逻辑重复 功能语义重复 代码重复执行 代码逻辑重复 比如UserService有两个方法,一个IsValidUserName校验用户名,一个IsValidPassword校验密码 type UserService2 struct{} func (s *UserService2) IsV
DRY原则 一、DRY原则 DRY原则:Don’t Repeat Yourselt, 简称DRY。 描述:不要重复自己,理解为不要写重复的代码。 三种典型的代码重复情况:实现逻辑重复、功能语义重复和代码执行重复。 实现逻辑重复,但功能语义不重复的代码。并不违反DRY原则。实现逻辑不重复,但功能语义重复的代码,也算违反DRY原则。代码执行重复也算违反DRY原则。 二、什么是代码复用性 区分三个概念:
设计原则之DRY 原则 DRY(Don’t Repeat Yourself),翻译成中文就是,不要重复你自己。这个原则最早出现在经典著作《程序员修炼之道》里,定义是这样的:系统的每一个功能都应该有唯一的实现,如果多次遇到同样的问题,就应该抽象出一个共同的解决方法,而不要重复开发同样的功能代码。 但是对于DRY原则,会比较容易陷入如下的一些思维陷阱中: 陷阱一:随时关心代码重用性 代码重复通常有
或许你听说过 DRY 原则,但我打赌,你理解的肯定有偏差;或许你从未听过,那太好了,本文会让你受益匪浅,对你的编码一定有指导作用,甚至对你的工作生活都有些许启发。 1 简介 DRY,Don’t Repeat Yourself 1.1 什么是 Repeat Yourself Repeat Yourself:多个地方表达相同的含义。 Repeat Yourself 的坏处: 变更其中一个,就必须记得变
1、不做重复的事(DRY:Don’t Repeat Yourself) 第一条准则是千万不要重复你自身。尽量在项目中减少重复的代码行,重复的方法,重复的模块。其实许多设计原则和模式最本质的思想都是在消除重复。我们经常提起的重用性和可维护性其实是基于减少重复这一简单的思想。 2、保持简单易懂(KISS:keep It simple & Stupid) 第二条准则是保持简单易懂。从小到几行代码的写法大
本文向大家介绍微服务架构中的DRY是什么?相关面试题,主要包含被问及微服务架构中的DRY是什么?时的应答技巧和注意事项,需要的朋友参考一下 DRY 代表不要重复自己。它基本上促进了重用代码的概念。这导致开发并共享库,但是反过来导致紧耦合。
问题内容: 例如, 按照上面的代码,我如何在不同模型上调用通用函数(调用a) 问题答案:
主要内容:1.图标制作,2.混淆,3.签名打包,4.APK瘦身,5.应用发布,6.小结不要问我为什么标题这么长,怎么不写短点,我觉得你是 代码虽然写完了,但是发布的后续操作还是挺多的,如标题, 本节讲述的内容依次是:应用图标的制作,混淆,签名打包APK,Apk瘦身, 以及发布应用到酷安市场。内容较多就不唠叨了,直接开始~ 1.图标制作 本来想着自己用Sketch做一枚的,摸索了10分钟不到就放弃了... 还是直接利用AS自带的图标生成工具一键生成算了,步骤如下: 右键drawabl
主要内容:1.一些BB,2.代码回顾,3.代码调整,4.编写日志工具类与崩溃日志采集类,5.小结1.一些BB 说来惭愧,DrySister的上一篇距今已经有一年多了,期间有不少小伙伴 都曾私信过我说写得很好,稳什么时候更,我基本都回复说太监了... 具体原因各种各样吧,最近一段时间比较闲,就想把第一版的完结了吧。 之前刚开始写的时候是AS 2.1.2,现在都AS 3.0.1了,本节的内容 依次是: Step 1:温习一波之前几节涉及到的东西 Step 2:代码在AS 3.0.1上跑要做一些调
主要内容:1.一些BB,2.开始编写程序,3.运行效果图,4.小结1.一些BB 上节我们为DrySister编写了一个异步图片加载缓存框架——SisterLoader(妹子加载器) 成功的从网络加载的图片缓存到了磁盘和内存中,当我们断开网络后,仍然能够查看这些图片, 但是,细心的你可能发现了一个很尴尬的地方,我们在有网的情况下进入APP,获取到图片相关 的信息,比如URL,如果退出了,断网,然后进来,图片就加载不出来了,图片已经缓存了,但是 我们没有图片对应的U
主要内容:1.一些BB,2.简单常识科普,3.简单的图片加载框架流程图,4.手撕代码时间,5.运行效果图,6.代码下载1.一些BB 上节我们把妹子图片的数据来源从本地改成了解析Gank提供的接口数据, 我们本节想对这个图片加载类进行优化,比如加上显示本地图片的,另外还有一点 就是缓存,我们现在用得图片加载没有任何缓存可言,每次都是请求后,解析流, 即使是同样的图片每次都要去请求一次,这显得有点累赘,把图片缓存到内存, 或者磁盘里,当访问相同的图片资源我们从这里拿?嗯,好像很有搞头,那么本节 我们
主要内容:1.一些BB,2.开始写代码,3.运行效果图,4.提交代码,合并分支,删除分支,Bug修复——(2016.8.9):1.一些BB 上节我们把简单的项目搭起来了,然后把仓库托管到Github上了,经过分析, 我们觉得有必要把下面两点优化下: 1.URL写死 -> 解析接口返回的Json,处理获取图片URL 2.优化图片加载,添加本地加载 本节就来完成上述的第一点! 2.开始写代码 1)在Develop上开辟功能分支:parse_json 2)抠脚Json解析接口数据 数据来源接口:Gan
主要内容:1.一些BB:,1.创建github仓库,2.开始编写程序,3.运行效果图,4.小结(本节过于简单,只是为了包吃连贯性,非小小白建议跳过!) 1.一些BB: 入门教程在上一年的11月份就写完了,到现在也有差不多9个多月了, 当时由于自己工作上的一些原因,没有写一个实战的项目,很是遗憾。 最近项目终于也差不多快收尾了,可能会稍微有一些时间,所以还是 决定把这个遗憾给填补上。毕竟入门教程学了那么多东西,肯定要写 个实战项目整合下,鉴于看入门系列的都是初学者和自己时间的关系, 这个项目