Javascript on 月盾的博客

原生js实现图片预览

Wed, 29 Jul 2020 03:45:04 +0000

不依赖jquery也可以实现图片预览功能：

<!--图片放大后的div 开始  这块粘贴在你的html中最后body前 -->
<div id="outerdiv" style="text-align: center;position: fixed;z-index: 9999;top: 0;left: 0;width: 100%;height: 100%;background-color: rgba(28,28,28,0.9);">
	<img id="bigimg" style="max-height: 800px;max-width: 100%;border: 0;margin: auto;position: absolute;top: 0;bottom: 0;left: 0;right: 0;" src="" />
</div>
<!--图片放大后的div 结束 这块粘贴在你的html中最后body前-->

<!--js开始 是放大点击的触发事件 这块粘贴在你的html中最后body前-->
<script type="text/javascript">
	//图片放大
	document.querySelector("#outerdiv").style.display = "none";
	document.querySelectorAll("img").forEach(function (item) {
		item.style.cursor = "pointer";
	});

	document.querySelectorAll("img").forEach(function (item) {
		item.addEventListener("click", function () {
			imgShow("#outerdiv", "#bigimg", this);
		})
	})

	function imgShow(outerdiv, bigimg, _this) {
		var src = _this.src;//获取当前点击的pimg元素中的src属性
		document.querySelector('#outerdiv').style.display = "block";
		document.querySelector(bigimg).src = src;//设置#bigimg元素的src属性
	}
	document.querySelector("#outerdiv").addEventListener("click", function () {
	//再次点击淡出消失弹出层
		document.querySelector('#outerdiv').style.display = "none";
	});
</script>
<!--js开始 是放大点击的触发事件 这块粘贴在你的html中最后body前-->

整体代码量少，实现也简单。效果如下：

你是拿锤子的前端开发吗？

Sun, 10 May 2020 03:44:34 +0000

前言

接上篇《说道说道前后端分离》今天再次对前端现状作一次分析（吐槽）。

再次引用一句《穷查理宝典》中的理论：

在手里拿着锤子的人看来，所有的东西都会是钉子。

因为有锤子的关系，遇到任何问题，都会先想如何用锤子解决。久而久之，陷入了一种思维定式。任何工具带来便利的同时，也带来了局限性。而这往往是用锤子的人很难看到的。

事出有因

这种现状在开发圈内决不少见，不仅限于前端。本文只说说前端的现状，原因是笔者最近在工作中遇到一个棘手的问题：性能优化。

最近接手了多个现有的前端项目，是公司比较核心的移动端官网，作为门户网站访问量和用户量都比较大，但是随着项目的迭代出现了性能问题，页面加载速度在WiFi网络下达到3s,3G网络15s以上，更差的网络40s+。加载的资源小则3M，大则6M。如果一切往好处想，假设所有用户使用最好的网络，用户和公司都不在乎流量费，两三秒的加载速度也还挺快的，每次打开页面费个3M流量也不是个事。但如果考虑这些问题的话就会发现这不是小问题。

对以上问题分析得出结论之一：资源过大，有兴趣的可以打开淘宝网看下首屏资源做下对比，可以看到资源不超过3M，时间不超过2s。

而我们一个移动端网站的资源居然能超过3M，究其原因：

图片大
js大
css大

图片大是因为图片基本没任何大小控制，都是使用了最高标准原图。js和css大基本是属于架构问题，一个项目中包含的上百的页面每个页面600多k的js是绕不过去的（vendor.js,app.js等打包资源，不包含其他引入资源）。

看到vendor.js,app.js这两个名称很多人应该想到了，这是vue（react）框架开发的网站。是的，就是用vue开发的移动端网站，使用vue开发网站本身也不是什么大问题，毕竟有实力的公司不需要SEO，直接竞价排名就行。而我要说的问题是，不是什么网站都可以用vue来开发，不信请继续往下看。

问题分析

我司的移动端网站作用并不仅仅是用来展示公司形象的，更重要的是用户转化的，就是让用户注册的。而且是要和很多第三方机构合作投放引流，经常需要分析页面UI的不同对转化率的影响，所以需要的页面不是几个，而是几十上百个，还在不停增加，每周都有三五个页面增加。由于vue主要是以开发单页SPA应用为主的，在开发人员不考虑真实需求的情况下自然会使用流行的技术，最终把网站开发成一个单页应用。单页应用的特点就是单页，就是把不同的页面做成一个页面一次加载，加载完成后页面之间的切换就会很快，一般无需再加载资源，用户体验也会好很多，可以套用一句话：“一次等待，处处快速”。

这个特点在管理后台项目中很合适，但是在只需要展示一次的项目中也合适吗？不合适。

我们的网站项目是用来做很多落地页的，各个落地页之间没有关联性，不会A页面跳到B页面，从B页面跳到C页面，A页面中不需要B页面的资源，B页面也不需要C页面的资源。然而vue项目打包的时候会把每个页面独有的一些资源都融合在一起，形成公共资源。结果就显而易见了，一个页面总要加载一堆无关资源，不仅资源大，还有很长的白屏时间，用户体验下降。

还有一点不该使用单页应用的原因是我们的页面是纯展示的页面，不需要很多数据交互，vue能起到什么作用？操作数据？驱动UI？模块化？通通不需要。现代html可以不借助第三方库和框架的情况下完全能实现。

结论

JavaScript 的最大优势之一是它不需要编译，所以可以在浏览器中直接运行。这样你就可以立刻获得编码的反馈。入门门槛很低；你只需一个文本编辑器和一个浏览器就能编写软件了。不幸的是，这种简单性和可访问性已被称为过度工具链的风气破坏了。这种风气已经将 JavaScript 的开发工作变成了一场噩梦。我甚至看过一整套关于配置 Webpack 的课程。这种乱象需要有个尽头——生命苦短啊。

VUE，React这类框架用于构建应用方面很合适，但不太适合构建网站。应用是需要有较多的UI和数据方面的交互，而网站则更多的是信息展示，你可能根本不需要JavaScript（框架）。

追求新技术可以让我们获得新奇感，成就感，解决老问题，而不是带来新问题。复杂性才是造成软件问题的根本原因。——试问：离开框架的你还会开发网站吗？

使用typescript开发nodejs的环境搭建（二）

Thu, 10 Nov 2016 09:30:27 +0000

完成了最基本的项目框架以后就是配置编辑器和编译选项，在没有特别配置的情况下，根目录下执行tsc会在ts后缀文件同级目录下生成js后缀的文件，这样也没什么不可以，但是在编辑器列表中看着有点混乱，生成的js文件是不建议直接修改的，就算修改了下次修改ts文件编译后也会重置文件内容。所以还是单独有个文件夹存放生成的js文件，这时就要配置tsconfig.json文件了。tsconfig.json文件可以通过tsc --init命令生成，自动生成内容比较简单，是可以直接使用的。以下的配置是经过一些特别需求配置的，可以直接复制一下内容到tsconfig.json文件中，然后根据自己的需求加减内容。其余参数可以参考:http://www.tslang.cn/docs/handbook/compiler-options.html

typescript编译配置

{
    "compilerOptions": {
        "module": "commonjs",//模块化规范
        "target": "es5",//生成js
        "noImplicitAny": true,//在表达式和声明上有隐含的'any'类型时报错
        "noImplicitReturns": true,//函数没有返回值提示
        "noFallthroughCasesInSwitch": true,//switch没有break提示
        "removeComments": true,//输出文件移除注释
        "noEmitOnError": true,//ts文件错误时不生成js
        "rootDir": "./",//需要编译的根目录
        "outDir": "./build",//编译文件输出目录
        "sourceMap": ture//是否生成.map文件，用于ts debug调试
    },
    "include": [
        "*/**/*.ts"
    ],
    "exclude": [
        //默认排除了node_modules
    ]    
}

为了能抛开在命令行中执行tsc命令，能直接通过vscode编辑器来编译，可以使用ctrl+shift+B快捷方式来编译ts文件。第一次使用会有提示

选择TypeScript - Watch-Mode，会在项目根目录下创建.vscode文件夹和tasks.json文件，内容如下：

vscode编译typescript配置

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "0.1.0",
    "command": "tsc",
    "isShellCommand": true,
    "args": ["-w", "-p", "."],
    "showOutput": "silent",
    "isWatching": true,
    "problemMatcher": "$tsc-watch"
}

这样就不用每次编译了，只要文件有修改就会自动编译

编译输出配置

为了将js文件输出到固定的目录，tsconfig.json中配置了"outDir": "./build"选项,会将ts文件编译到build目录下，得到了下面的文件目录结构：

.
├── app.ts
├── bin
│   └── www.ts
├── build
│   ├── app.js
│   ├── app.js.map
│   ├── bin
│   ├── public
│   ├── routes
│   ├── utils
│   └── views
├── node_modules
├── package.json
├── README.md
├── routes
│   ├── index.ts
│   ├── test.js
│   └── users.ts
├── test
├── tsconfig.json
├── typings
│   ├── globals
│   ├── index.d.ts
│   └── modules
├── typings.json
└── utils
    ├── cover.ts
    └── route.ts

build的目录下包含了public目录和views目录，这并不是编译生成的，因为最后执行的文件是js文件，为了与原来的express框架目录保持一致，手动将public和views等文件夹拷贝进去。

Nodejs核心常用工具

Thu, 30 Oct 2014 08:30:38 +0000

内容摘自《nodejs开发指南》

util 是一个 Node.js 核心模块，提供常用函数的集合，用于弥补核心 JavaScript 的功能
过于精简的不足。
util.inherits
util.inherits(constructor, superConstructor)是一个实现对象间原型继承
的函数。JavaScript 的面向对象特性是基于原型的，与常见的基于类的不同。JavaScript 没有
提供对象继承的语言级别特性，而是通过原型复制来实现的，具体细节我们在附录A中讨论，
在这里我们只介绍 util.inherits 的用法，示例如下：

var util = require("util");   
  
function Base() {   
  this.name = "base";   
  this.base = 1991;   
  
  this.sayHello = function() {   
    console.log("Hello " + this.name);   
  };   
}   
  
Base.prototype.showName = function() {   
  console.log(this.name);   
  
};   
  
function Sub() {   
  this.name = "sub";   
}   
  
util.inherits(Sub, Base);   
  
var objBase = new Base();   
objBase.showName();   
objBase.sayHello();   
console.log(objBase);   
  
var objSub = new Sub();   
objSub.showName();   
//objSub.sayHello();   
console.log(objSub);

我们定义了一个基础对象 Base 和一个继承自 Base 的 Sub，Base 有三个在构造函数
内定义的属性和一个原型中定义的函数，通过 util.inherits 实现继承。运行结果如下:

base   
Hello base   
{ name: "base", base: 1991, sayHello: [Function] }   
sub   
{ name: "sub" }

注意，Sub 仅仅继承了 Base 在原型中定义的函数，而构造函数内部创造的 base 属
性和 sayHello 函数都没有被 Sub 继承。同时，在原型中定义的属性不会被 console.log 作
为对象的属性输出。如果我们去掉 objSub.sayHello(); 这行的注释，将会看到：