export import default of ES(JS)

  • The Asynchronous Module Definition (AMD) format is used in browsers and uses a define function to define modules.
  • The CommonJS (CJS) format is used in Node.js and uses require and module.exports to define dependencies and modules. The npm ecosystem is built upon this format.
  • The ES Module (ESM) format. As of ES6 (ES2015), JavaScript supports a native module format. It uses an export keyword to export a module’s public API and an import keyword to import it.
  • The System.register format was designed to support ES6 modules within ES5.
  • The Universal Module Definition (UMD) format can be used both in the browser and in Node.js. It’s useful when a module needs to be imported by a number of different module loaders.

A background on modules

JavaScript programs started off pretty small — most of its usage in the early days was to do isolated scripting tasks, providing a bit of interactivity to your web pages where needed, so large scripts were generally not needed. Fast forward a few years and we now have complete applications being run in browsers with a lot of JavaScript, as well as JavaScript being used in other contexts (Node.js, for example).

It has therefore made sense in recent years to start thinking about providing mechanisms for splitting JavaScript programs up into separate modules that can be imported when needed. Node.js has had this ability for a long time, and there are a number of JavaScript libraries and frameworks that enable module usage (for example, other CommonJS and AMD-based module systems like RequireJS, and more recently Webpack and Babel).

The good news is that modern browsers have started to support module functionality natively, and this is what this article is all about. This can only be a good thing — browsers can optimize loading of modules, making it more efficient than having to use a library and do all of that extra client-side processing and extra round trips.

Introducing an example

To demonstrate usage of modules, we’ve created a simple set of examples that you can find on GitHub. These examples demonstrate a simple set of modules that create a <canvas> element on a webpage, and then draw (and report information about) different shapes on the canvas.

These are fairly trivial, but have been kept deliberately simple to demonstrate modules clearly.

Note: If you want to download the examples and run them locally, you’ll need to run them through a local web server.

Continue reading “export import default of ES(JS)”

AutoStartDesktop, 一个关系祖国未来的免费软件

[2020/03/02 V1.1.1]

更新:

  1. 支持新功能:应用图标
  2. 支持选择应用,你可以不用手动填写应用路径了
  3. 添加中英文双语支持

详细:

  1. 主界面

支持应用图标的显示

  1. 添加应用Add App
    1. 现在你可以不用手动填写应用路径了,点击按钮Choose App会打开文件选择对话框,然后找到你所需要的应用,应用图标也会一并显示在界面上

Continue reading “AutoStartDesktop, 一个关系祖国未来的免费软件”

适配器模式 (Adapter Pattern)-结构型模式第三篇

祖国母亲生病了,一场突如其来的新冠病毒让这个古老的中华民族正在经历一场全民参与、没有硝烟、却生离死别的战争。每每看到抖音里的那些感人场景虽然不至于声泪俱下,却也是感慨万千、悲愤不已。大家现在都蛰伏在家,等待时机成熟破茧化蝶。相信这个春节在很多人的记忆里永远再也无法抹去,只希望所有人都安好!岁岁平安!

想起抖音里某位才人拍摄的一段视频,视频里这位仁兄使用女用卫生巾夹在普通一次性口罩中混合使用,以提高过滤功效。感叹一句,此乃神人也,有才,不得不佩服!笑归笑,这里不禁想起了设计模式中一个称之谓适配器(Adapter)的模式,所谓Adapter模式简言之,适配器能够使原本两个不兼容的接口能够协同工作。这位才人他没有将卫生巾直接戴在嘴上、卡在脸上(那可不适配),而是通过一个一次性口罩进行了转换、隐藏、适配,然后交由一次性口罩来担负起对外的形象任务,抽象一点的说其实这也算是一个适配器模式的应用:)

好吧,让我们来正式认识一下Adapter模式吧! Continue reading “适配器模式 (Adapter Pattern)-结构型模式第三篇”

SAP Business One

今天我们不说技术也不说设计,我们闲聊一下SAP B1,其实对于我这样一个门外汉来说,B1我是完全不懂的,但最近由于工作上的需要,也出于自己的一些兴趣,硬着头皮看了一些有关的B1的文档,总结出以下几点:

B1 SDK

B1的随行安装包中提供有能够进行二次开发的SDK工具包,提供的API主要分布在两个Namespace,分别为SAPbouiCOM和SAPbobsCOM,它们提供的功能分别是:

  1. SAPbouiCOM用来操作B1 Client UI,也就是我们平常所说的UI API,通过该命名空间下的API接口能够做什么呢?
    1. 粗略看来,在该命名空间下提供了丰富的interop接口,日常工作状态下,人类用鼠标可以操作的,似乎在该命名空间下都有相应的接口,比如打开一个PO,删除一行line,修改某个Comments等
    2. 此外除了可以操纵B1 Client以外,在该命名空间下,还内建了一些B1标准UI Controls,它们可以用来创建与B1 Client风格一致的UI界面
  2. 那么SAPbobsCOM,也即DI API,它又是用来干什么的呢?
    1. 我们知道任何UI的操作,最终是去操作data,无论是direct还是rpc,DI API封装了能够支撑B1 Client运行的所有业务逻辑,实际上,我们通过UI API去操作B1 Client,在其背后便是UI API去调用DI API来执行。
    2. 这便给了我们足够的能力,通过DI API来构建不同的服务或应用程序,比如在B1安装包中所附带的B1 Integration Framework,它对于B1的支持便是利用DI API来实现。

演示

下面通过一个简单的例子,来加深大家对于B1 SDK的理解。它使用了UI API来创建与B1 Client风格一致的用户界面,如果想自由定制,可以阅读我的另一篇文章(B1i Daily Issue Resolver它通过DI API创建了一个与B1 Client有相似功能的登陆界面),似乎如果你有足够的耐心,你能够通过DI API构建另一个B1

  1. 添加一个新的子菜单FormX到MRP菜单中
  2. 点击Foo Button,弹出消息对话框
  3. 将自定义的数据集显示在内建的Grid控件中
  4. 将B1的数据显示在内建的Matrix控件中(注意这里查询出的数据结果是由B1 API来实现,而并非直接通过SQL,即是说API提供了一定的条件筛选和查询能力,自然如果产生无法满足需求的状况,它也提供了备选策略:直接操作SQL的能力)
  5. 点击每行前的箭头,打开相应的Order

组合模式 (Composite Pattern)-结构型模式第二篇

静悄悄中时间飞逝,感叹一句最近TMD真忙真累,好在天生坚强性格阳光,不吹不黑,下面开始讲结构型模式(Structural patterns)的第2篇,Composite Pattern,中文称之为组合或复合模式。

定义:

Composite模式,能够灵活地实现循环、递归、部分-整体类的结构,使外部世界能够以一致的方式处理单体或集合。

解决的问题:

  1. 就像定义中所提及的那样,如何使客户端能够以一致的方式去访问某个单体或者集合,以使结构更加简洁
  2. 如何优雅的表达一个树形结构

怎么去解决(包含叶子Leaf的实现方式):

  1. 通过定义一个接口代表集合与个体所拥有的相同属性与行为,如IComponent
  2. 通过定义一个类Composite,它继承自IComponent,同时通过组合的方式它拥有一个名称为Components的属性,它代表着一个IComponent集合
  3. Composite有能力将一个实现了IComponent接口的对象加入到Components中
  4. 对于Composite的任何请求,都会被重定向到属性Components中的每个个体分别去执行
  5. 通过定义一个类Leaf,它继承自IComponent,代表着不可再分割的个体

举个栗子,在一个树状结构中,树杆、树枝、树叉皆由Composite来表示,而Leaf代表的是末端的每片树叶。

怎么去解决(进一步抽象):

通过分析我们能够发现在上面的解决方式中,如果有能力分辨一个IComponent是树杆还是树叶,便可以将Composite和Leaf合并为一个类型,于是我们为IComponent引入一个新的属性HasChild,并且给它换一个更贴切的名字INode,如果HasChild为True,则代表它是Composite,反之则代表它是Leaf Continue reading “组合模式 (Composite Pattern)-结构型模式第二篇”

Visual Studio Code的设计亮点

本文转自网络,原文网址 https://zhuanlan.zhihu.com/p/35303567

Visual Studio Code(VS Code)近年来获得了爆炸式增长,成为广大开发者工具库中的必备神器。它作为一个开源项目,也吸引了无数第三方开发者和终端用户,成为顶尖开源项目之一。它在功能上做到了够用,体验上做到了好用,更在拥有海量插件的情况下做到了简洁流畅,实属难能可贵。

我是VS Code用户,同时也为它开发插件,插件市场里的众多Java插件基本都是我们团队的作品,所以我在日常工作中观察到不少VS Code在工程方面的亮点,下面就来逐一探讨。

简洁而聚焦的产品定位,贯穿始终

你知道VS Code的开发团队人数不多吗?难以相信吧,大家都觉得VS Code无所不能,如此强大的工具那么几个人怎么做得出来。实际上功能丰富是个美好的错觉,因为大部分针对特定编程语言和技术的功能都是第三方插件提供的,VS Code的核心始终非常精简,这很考验产品团队的拿捏能力:做多了,臃肿,人手也不够;做少了,太弱,没人用。他们团队选择了专注于核心功能的开发,为用户提供简洁流畅的体验,并将该思路贯穿在产品开发的每个环节。在我看来,这就是第一个亮点。 Continue reading “Visual Studio Code的设计亮点”

装饰者模式 (Decorator Pattern)-结构型模式第一篇

本篇是结构型模式(Structural patterns)的第一篇,之所以选择Decorator模式第一个出场,是由于抓揪随机的结果。Decorator模式能够为行为带来灵活的组合,减少子类的数量,希望文章能够给大家带来一点帮助。

定义:

Decorator模式,能够将行为动态地添加到一个类型实例,而不会影响其它的实例。

解决的问题:

  1. 如何在运行时给一个对象添加新的行为
  2. 如何减少子类的数量
    1. 我们知道通过新建一个子类,也能够为类型添加新的行为,但是它存在一个明显的缺陷:随着新行为数目的不断增加,需要增加更多数目的子类,并且行为之间无法组合使用

怎么去解决:

  1. 通过定义一个接口代表原始对象本身,如IComponent
  2. 通过定义一个接口IDecorator,它继承自IComponent,同时通过组合的方式它拥有IComponent
  3. 对于IDecorator的任何请求,都会被重定向到IComponent,并且在重定向前后我们有能力添加新的行为

UML:


Continue reading “装饰者模式 (Decorator Pattern)-结构型模式第一篇”

原型模式(Prototype Pattern)-创建型模式第五篇

距离发布上篇软件设计模式文章《建造者模式》稍稍地已经过去两个多月,今天来谈一下第五个创建型模式,这也将是最后一个创建型模式——原型模式(Prototype Pattern)。

定义:

Prototype模式,通过将对象自身进行复制来创建新的对象。多么简单的定义,该模式也很简单。

解决的问题:

  1. 在运行时如何动态创建一个对象的副本

怎么去解决:

  1. 通过定义一个含有Clone方法的Prototype接口
  2. 具体的实现类通过继承Prototype接口来创建自身的复制品

UML:

Continue reading “原型模式(Prototype Pattern)-创建型模式第五篇”

建造者模式(Builder Pattern)-创建型模式第四篇

也许得写一个段落放在文章的开头才会显得整篇没那么单调,我想写些什么,但指头落下的那一刻便忘了。简言之,设计模式犹如人生。好吧,也许这就算一个简单的开头,请让我们来看今天的主角,建造者模式(Builder Pattern),我不确定中文称它建造者模式是否准确,偶尔也会看到有人称其构建者或生成器模式。

定义:

Builder模式,通过将对象的构造过程与其本身分离开来,以简化复杂对象的创建过程,并且能够实现相同的构造过程可以创建不同的对象。

解决的问题:

  1. 如何通过简单的方式创建一个复杂的对象
  2. 如何通过相同的过程来创建类的不同实例

怎么去解决:

  1. 在一个独立的Builder对象中去创建和组装复杂对象的各个部分
  2. 通过对Builder的抽象,在创建复杂对象的过程中委托给具有相同接口的不同Builder实现,以达到相同的过程创建不同的对象

UML:

Continue reading “建造者模式(Builder Pattern)-创建型模式第四篇”