分享几个写 demo 的思路

2,221 阅读6分钟

好久没有动笔,最近发现了一个新的写 demo 的思路,非常有意思。仔细一想,自己仿佛积累了不少写 demo 的思路和想法,总结一下,抛砖引玉。

本文所说 demo 主要分以下三种:

  • 本地 demo
  • 外链 demo
  • 文章中带 demo

本地 demo

楼主在工作和学习中是比较喜欢写 demo 的,抛出问题非常直观。

本地写 demo,爱咋整就可以咋整,简单到可以只有一个 HTML 文件,复杂到引入 React / Vue 等框架类库,视情况而定。对于楼主来说,多数情况下是一个 HTML 文件就可以搞定的。最方便的情况下,直接新建个 HTML 文件,然后起一个本地 server 即可,本地 server 可以用 Python、PHP 等起,对于前端来说,http-server 是个不错的选择,然后再配置个 alias,比如我在 .zshrc 中配置 alias s="http-server",可以秒启。如果是稍微复杂的情况,需要些许调试,那么修改后自动刷新是必须的,我写了一个简单的脚手架 gulp-simple 可以满足这个需求。但是我比较懒,觉得这样还不太方便,毕竟需要编辑器和浏览器两边切换查看效果(单屏的情况下),有时只是查看一个简单的 css 特性,这样搞就显得麻烦了,我又给自己开发了两个简单的在线编辑器,分别是 html editor1 以及 html editor2,方便调试简单的 html 页面。

本地 demo 大概三个方式,总结下:

  • 本地新建 HTML 文件,双击启动或者本地启 server
  • 使用 gulp-simple(需要简单调试的页面)
  • 使用 html editor1 或者 html editor2 在线编辑以及调试

外链 demo

你写了个炫酷的页面,希望分享给别人,如果把 HTML 文件发给别人,显然不是一个好的想法,最简单的方式就是将文件上传到服务器,发送链接给别人,也正是接下去要说的外链 demo。

最方便的选择是选择第三方服务,类似 codepen 或者 jsfiddle,国内的 runjs 也做的不错可以试试。(这些网站均有很多不错的 demo,可以看看实现)

因为个人是重度 GitHub 用户,自从知道 GitHub Pages 这玩意后,一般的外链 demo 都放在那了,所以 GitHub Pages 也不失为一个好的选择。(点这里 看我的全部 demo)

说到 GitHub Pages,其实 GitHub 中的 repo 中的静态 HTML 页面也是可以查看效果的(归根结底还是 GitHub Pages),通常用来生成项目主页等。具体设置在具体 repo 的 Settings -> Options -> GitHub Pages 中,选择分支(一般是 master branch 即可),点击 save 即可,比如我在 codedog 项目中生成的 demo。还有另一个方法,进入 GitHub & BitBucket HTML Preview 这个网站,生成静态页面链接,但是只适用于只有一个 HTML 页面的场景,如果有引用 css 的话路径会错误。

另外,如果有自己的服务器,那么很显然部署到自己的服务器就可以了。

外链 demo 同样大概三个方式,总结下:

文章中带 demo

重点重点,这才是本文的重点!

有的时候写文章,需要配个简单的 demo,怎么破?外链当然可以,但是没有直接显示在文章中显得直观。

首先, codepen / jsfiddle / runjs 应该都是支持 iframe 插入页面的,但是我一般不这么做,首先 iframe 加载可能会太慢影响体验,其次依赖于第三方总觉得不安全,而且很多的第三方服务并不一定支持 iframe 的插入。

然后以前用新页面打开来查看页面效果,可以看下很久前写的 这篇文章,核心和 html editor1 以及 html editor2 两个在线编辑器的新页面预览的实现一致,即新建个窗口:

function runCode() {
  let code = editor.getValue()
  let handler = window.open('')
  handler.opener = null
  handler.document.write(code)
  handler.document.close()
}

但是惊讶地发现在博客园该方式已经失效!我猜测 window.open('') 被博客园给过滤掉了,所以这个方案基本已经完蛋。以前在博客园看到过页面中直接显示 css 效果的,我猜测实现应该是一样,直接混入了 html 代码,自从接触 markdown 后,我便完全抛弃了富文本编辑器,所以总觉得这样的实现有点 "脏",但是一直苦于没有一个好的实现。

我理想中的状态是,可以用 markdown 写文章,但是文章中有些代码可以查看 HTML 效果。最后,我开发了 codedog 这个工具,用 markdown 写文章,自动生成 html 文件,比如我前段时间在看 《CSS 揭秘》这本书,我用 markdown 做笔记,用 codedog 生成的 HTML 可以方便查看 CSS 效果,而且支持在线编辑,简直是爽,具体实现效果可以 点击这里 查看。

但是 codedog 这个工具是为了这个需求量身定做的,有一定的局限性,有时候要实现文章中带 demo 的效果,不得不在 markdown 和 HTML 中取舍,比如我之前为了学习 flex 写的 这个 demo,是纯 HTML 写的,且存在一定的特殊性(不可复用)

最后就要说到文章开头说的 “发现了一个新的写 demo 的思路”,做到首尾呼应,是什么呢?

通过设置 style 标签的 display:block 样式可以让页面的 style 标签显示出来,并且加上 contentEditable 属性后可以让样式成为可编辑状态,更改后的样式效果也是实时更新呈现,这就给交互创造了新的可能。

之前的实现如果页面有样式,并且修改样式直接预览(类似 html editor1 或者 html editor2 ),其实实现是获取 value 然后再插入 HTML 文档流中,而通过设置 style 标签的 display:block 样式,操作的就是实际的样式,不需要拐弯抹角。

<!DOCTYPE html>
<html>
 <body>
    <style style="display:block" contentEditable>
      body { color: blue }
    </style>
 </body>
</html>

写了个简单的 demo 可以看下,确实是另一种思路。

所以说,"文章中带 demo" 所说的 "文章" 实现,可能是 HTML 的,也可能是 markdown 的,具体如何,需要视情况而定了。

总结下:

  • 如果是 markdown 写的文章(如果需要涉及 inline 的 demo),最后肯定是要编译成 HTML 预览,思路类似 codedog
  • 如果直接用 HTML 写文章,类似 这个,那么我觉得复用性其实不是很高,毕竟交互方式是不一样的(也可以没有交互),这个时候(如果有交互),可以试试 <style style="display:block" contentEditable> 这种方式。

总结

总结就不总结了,都在上面了,如果有补充,热烈欢迎 👏