less是写css时可以采用的另一种写法,用less的格式写出来的东西,可以通过编译器编译成css。也就是可以使用某种方法,把less文件变成css文件。编译成的css文件和平时自己写的css没什么区别,浏览器自动可读
javascript是一门弱类型语言, 所谓弱类型, 就是一个变量既可以被赋值字符串, 数字, 又可以被赋值数组, 对象, 弱类型的好处很多, 但也有缺点, 比如:
在 html 里指定 class,然后在 css 里定义这个 class 的样式。
看了上面的两个案例我想大家应该就知道为什么 React 要打造 jsx 了,因为他写模板就像我们写原生 html 一样,但是因为我们浏览器是不认识 jsx 的,最终还是会通过 babel 编译成 js 写的那样,所以说 jsx 是原生 js 创建虚拟 DOM 的语法糖
这个括号的目的,是为了把function(){}转化为表达式。像一些库的源码,喜欢用如下方式代替:
上一篇《浅谈HTML5单页面架构(一)——requirejs + angular + angular-route》探讨了angular+requirejs的一个简单架构,这一篇继续来看看backbon
opacity是CSS中很有意思的属性,类似于Photoshop中不透明度的更改,结合绝对定位能实现很多漂亮的效果。
前端开发是一个细节分支特别多的行业,如果用一个水果来比喻的话,我觉得“红毛丹”特别形像,就是这个东西, 你看它外面的细毛很多,但没有哪一根毛可以单独支撑起它自身。需要它周身所有的毛什么的东西一起,才能
ES6初学者,通过阅读本文可对ES6知识点有个大体的概念,强烈建议阅读阮一峰大大的ES6入门。
上面的示例是一个正则的校验,正常来说直接调用check函数就可以了,但是如果我有很多地方都要校验是否有数字,其实就是需要将第一个参数reg进行复用,这样别的地方就能够直接调用hasNumber,hasLetter等函数,让参数能够复用,调用起来也更方便。
封闭函数是javascript中匿名函数的另外一种写法,创建一个一开始就执行而不用命名的函数。
写法一:让函数内部的this指向这个类的实例,它是用bind实现的,bind的第一个参数表示context,就是this。
JavaScript开发的过程中,处理浏览器的兼容很复杂而且很耗时,于是一些封装了这些操作的库应运而生。这些库还会把一些常用的代码进行封装。
从Library的角度去看,Ext(喜欢中文的朋友可以到它的中文站看看)和Prototype JQuery YUI没有太大区别,但它有它的优点,完整的OO支持、成熟的通用widgets并支持主题、良好
历史上,JavaScript 一直没有模块(module)体系,无法将一个大程序拆分成互相依赖的小文件,再用简单的方法拼装起来。其他语言都有这项功能,比如 Ruby 的require、Python 的import,甚至就连 CSS 都有@import,但是 JavaScript 任何这方面的支持都没有,这对开发大型的、复杂的项目形成了巨大障碍。 在 ES6 之前,社区制定了一些模块加载方案,最主要的有 CommonJS 和 AMD 两种。前者用于服务器,后者用于浏览器。ES6 在语言标准的层面上,实现了模块功能,而且实现得相当简单,完全可以取代 CommonJS 和 AMD 规范,成为浏览器和服务器通用的模块解决方案。
CommonJS中规定每个文件是一个模块。每个模块是拥有各自的作用域的,各自作用域的变量互不影响。
这几天在公司接手了一个项目,是之前其它组的,现在要继续完成它。那我要做的第一件事,就是熟悉代码。对,就是看别人写的JS代码。文档嘛,自然是没有的。 之前也有试过看代码,但项目中N多JS文件,每个JS文件上千行,一行一行的看下来,用不了几分钟就完全晕掉了。完全不知道某一行里的判断,是在判断什么,那个变量是什么意思,顺着调用顺序看下来,会发现看到后面的时候,前面看的内容已经忘了。 于是,这一次,我决定换一个方式读JS源码。 这个项目中有N个JS文件,我把入口的JS文件拿出来先看,然后我把它里面所有的函数名,都用
CSS-in-JS是一种技术(technique),而不是一个具体的库实现(library)。简单来说CSS-in-JS就是将应用的CSS样式写在JavaScript文件里面,而不是独立为一些 .css, .scss或者 less之类的文件,这样你就可以在CSS中使用一些属于JS的诸如模块声明,变量定义,函数调用和条件判断等语言特性来提供灵活的可扩展的样式定义。值得一提的是,虽然CSS-in-JS不是一种很新的技术,可是它在国内普及度好像并不是很高,它当初的出现是因为一些 component-based的Web框架(例如React,Vue和Angular)的逐渐流行,使得开发者也想将组件的CSS样式也一块封装到组件中去以解决原生CSS写法的一系列问题。还有就是CSS-in-JS在React社区的热度是最高的,这是因为React本身不会管用户怎么去为组件定义样式的问题,而Vue和Angular都有属于框架自己的一套定义样式的方案。
本篇参考:https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Functions/Arrow_functions
https://developers.weixin.qq.com/miniprogram/dev/api/storage/wx.getStorage.html
本系列面试题旨在学会相关知识点,从而轻松应对面试题的各种形式,本文讲解了 JavaScript 中 this 指向问题以及模块化。
Vue可以自底向上逐层的应用简单应用:只需一个轻量小巧的核心库复杂应用:可以引入各式各样的Vue插件
也就是后来的 common.js ,AMD, es6 ,CMD这些。。这些就下次再说了,
心血来潮,打算结合实际开发的经验,浅谈一下HTML5单页面App或网页的架构。 众所周知,现在移动Webapp越来越多,例如天猫、京东、国美这些都是很好的例子。而在Webapp中,又要数单页面架构体验最好,更像原生app。简单来说,单页面App不需要频繁切换网页,可以局部刷新,整个加载流畅度会好很多。 废话就不多说了,直接到正题吧,浅谈一下我自己理解的几种单页面架构: 1、requirejs+angular+angular-route(+zepto) 最后这个zepto可有可无,主要是给团队中实在用不爽
这里我们可以看到, 第一行中的a虽然还没声明, 但是我们用起来却不会报错。这种情况, 就是变量声明的提升。
继续讲下一般人(这里的一般人指的是一般不写正则的人)不经常用的功能: 1、忽略优先量词 包括:*?、+?、??、{num, num}? 。这几类和后面没有加?的量词的区别就是:前者会匹配尽可能少的内容
得益于会react,会点jQuery,也会点vue,研究了一下小程序,发现这东西有好处也有坏处。
去年(19年10月)在某技术沙龙上分享了《小程序工程化探索》后,陆续有网友联系到我询问一些实现方面的细节,虽然常年顶着黑眼圈修着“福报”,但还是决定抽出时间写一个小程序工程化系列,一是希望能帮到部分同学,二是希望能提升自己的总结与表达能力,由于是一个系列,所以每篇文章会尽量聚焦一个点,篇幅不会很长。闲话少述,本篇是小程序工程化系列第一篇,我将会详细介绍如何利用 Webpack 实现对小程序代码的文件依赖分析。
方式一:用媒体查询"@media",这种写法好处是可以对不同分辨率的设备,展示完全不同的UI界面,一个页面不同的设备看的时候,展示内容可以不一样,交互方式可以不一样。不过这个不方便用在复杂的地方,而且不同的分辨率都需要对应的重新写样式,同一个页面集合太多的这种写法,最好是分开写两套,降低耦合性。但是这种写法费力不讨好,之前有的网站在PC和手机查看到的样式不一致,用了一些这个技术,但是后来很多都是检测到不同设备,就跳转到不同的网页上去了。
我们知道,在我们设计微信小程序时,我们经常会用到开发者工具中提供的许多标签,例如:
公司开发了自己的组件库,组件的样式基于tailwindcss进行开发,所以近期项目重构时,技术组长要求使用tailwindcss,说实话一开始我是排斥的,心想着tailwindcss最后不也是解析成css,但是组长要求了,我就照做,于是开始马不停蹄的学习起来tailwindcss了。
这不是跟React Hooks很像吗?大家看到的第一感觉是这样,但看完整篇文章之后,会发现比React Hooks更简单且更亲切了一点,Function-based的Script写法跟原本Vue 2.x的写法有一点不太一样,对于原本写习惯2.x的朋友来说可能会不习惯,但是对于初学Vue的朋友来说,学习曲线可能会更低一些而且非常好上手。
ES6标准发布后,module成为标准,标准的使用是以export指令导出接口,以import引入模块,但是在我们一贯的node模块中,我们采用的是CommonJS规范,使用require引入模块,使
ES6标准发布后,module成为标准,标准的使用是以export指令导出接口,以import引入模块,但是在我们一贯的node模块中,我们采用的是CommonJS规范,使用require引入模块,使用module.exports导出接口。
AMD(常用在浏览器端,异步的,如requirejs)(Asynchronous Module Definition)
截止目前,React Server Component 还在开发与研究中,因此不适合投入生产环境使用。但其概念非常有趣,值得技术人学习。
会上讲了很多激动人心的技术点,这里先介绍一些我比较感兴趣的点, 希望对大家有所启发。
ORM:Object-relational mapping,是把对象和关系型数据库建立映射的过程。 实际应用开发中,基本都会引入 ORM 来辅助操作数据库,通常被提及的好处,例如:
文章目录 模块化介绍 准备工作 注意事项 html中基本使用 注意的点 导出方式-〉默认导出 导出一个匿名函数:moduleDefault.mjs 运行该匿名函数 导出一个非匿名函数 运行该模块函数 注意事项 模块处理-〉非默认 基本用法 tools.mjs use.js 避免命名冲突->重命名导入与导出 导出使用别名 导入使用 避免不同文件相同函数名字-> 创建模块对象 使用模块对象化 类的导出 模块化合并操作 tools.js 汇总该导出 使用方式一 : 正常引入 使用方式二: 合并引入 动态加载模块
首先说明一下,这个已经是老框架了,不建议使用,只是当做了解一下过去的知识,或者学习一下源代码,知道过去的模块化开发是什么样的,模块化开发的好处,API 快速参考
其实vue加载远程js的教程很多,但是我比较笨呐。。。用不出来,每次都报方法/属性不存在的错误,来看一下典型的写法:
当前我在使用的版本用的是 Calcit-js 代替 ClojureScript 在跑, 原理其实是一样的, 只是自己定制了 API 和工具链. 注意的是, ClojureScript 跟 JSX 相似, 都是动态类型语言, 编译到 JavaScript 运行, 通过 Webpack/Vite 工具链提供热替换功能.
尾调用是函数式编程中一个很重要的概念,当一个函数执行时的最后一个步骤是返回另一个函数的调用,这就叫做尾调用。
阿特伍德定律,指的是any application that can be written in JavaScript, will eventually be written in JavaScript,意即“任何可以用JavaScript来写的应用,最终都将用JavaScript来写”在使用新技术的时候,切忌要一步一步的来,如果当你尝试把两门不熟悉的新技术一起结合使用,你很大概率会被按在地上摩擦,会yarn/npm和React脚手架等技术是前提,后面我会继续写PWA深入和Node.js集群负载均衡Ngi
回首对nodejs的源码研究,时间已经过去了一年多。我很喜欢js这门语言,有时候感觉他和c语言一样,在c语言里,很多东西都需要自己实现,让我们可以发挥无限的创造力和想象力,js虽然很多东西在v8里已经提供,但是用js,依然可以创造很多好玩的东西,还有好玩的写法。js应该我见过唯一的一门没有实现网络和文件功能的语言。或者说没有向用户提供这种功能。这也是我对js最大的偏见。因为网络和文件,是一个很重要的能力。对于程序员来说,也是很核心很基础的知识。因为js的使用场景是运行在浏览器。如果js提供了文件操作的话,这就意味着js可以访问用户电脑上面的数据,这也是不显示的,所以,js不可能会提供这样的能力,让我们可以像其他语言一样,随意操作用户的资源。
JavaScript 语言是采用单线程模型,也就是任务只能在一个线程上完成,一次只能做一件事,前面任务没执行完,后面的任务只能排队等待,由于多核 CPU 的出现,单线程带来很大不便,无法充分发挥计算机的能力。
本文主要介绍了如何将一个使用webpack构建的web应用打包为适用于各浏览器的可执行文件。首先介绍了webpack和browserify的区别,然后说明了webpack的配置文件,紧接着介绍了如何设置多入口,并分析了生产环境基于node的webpack如何处理。最后,作者分享了如何对css、js代码进行压缩、图片进行优化以及支持多入口的打包结果。
JavaScript 语言采用的是单线程模型,也就是说,所有任务只能在一个线程上完成,一次只能做一件事。前面的任务没做完,后面的任务只能等着。随着电脑计算能力的增强,尤其是多核 CPU 的出现,单线程带来很大的不便,无法充分发挥计算机的计算能力。
无论ReactJs还是其它什么,我们在看的时候都要看它们的思路、方面,而不要一开始时就扎进它的代码细节中。。。 最近在看一些reactJs的资料,有一些收获,写成文章跟大家分享一下,其中很自然的也会有我自己的一些主观看法,请大家批判的阅读。 React这个东西是facebook搞出来的,如果是国内搞出来的是否还能还能这么火么?这个问题是我在知乎上看到的。这个问题的出发点很有意思,不去探究react本身如何,而是去撕它背后的干爹,呵呵 我为什么提这个问题呢,因为这个问题的立场是我个人主观上最反感的。 我的立场
领取专属 10元无门槛券
手把手带您无忧上云