https://webpack.js.org/concepts/
不得不安装 WebPack 来…… 解决 JavaScript 模块的打包问题
话说这 WebPack 的理念还真多啊,而且连告诉用户,它需要用 CLI
不得不安装 WebPack 来…… 解决 JavaScript 模块的打包问题
话说这 WebPack 的理念还真多啊,而且连告诉用户,它需要用 CLI
npm install -g webpack-cli 都懒得讲。webpack
Concepts | webpack
webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.
npm install --save-dev webpack 真是啰嗦,说好的不需要任何配置呢?
我讨厌
node_modules,真是智障缓存方式
duangsuse::Echo
或许我不该写得这么莫名其妙的,但既然能用,而且只是难看了一点,算了…… (主要是这么写理论上没有任何问题)
不是难看了一点,难看的东西都有问题!
我今天早上吃饭时想了一会,基本熟悉了它的工作方式:
+ no-dependencies = null
+ have-dependencies = each-dependency-with-their-dependencies ?? [itself]
后来我一想,不对啊
再一想,自己早在还没弄自动依赖解析之前就已经犯了这个错误,但那时候是情有可原,因为没
然后我发现这是因为没有完全重写,误会了 (??) operator 导致的一个设计问题…… 其实 deepDependencies 的基线完全可以是
我今天早上吃饭时想了一会,基本熟悉了它的工作方式:
+ no-dependencies = null
+ have-dependencies = each-dependency-with-their-dependencies ?? [itself]
后来我一想,不对啊
xs?.concat(x) ?? [x] 这不是等于 (xs ?? []).concat(x) 吗?再一想,自己早在还没弄自动依赖解析之前就已经犯了这个错误,但那时候是情有可原,因为没
depend DOM Attribute 就的确是『没有依赖』,但现在不行啊!deepDependencies 本来就应该返回 Array<Element> 而非 Array<Element>?
艹,如果是 Kotlin 我肯定不会犯这种错误!都怪 TS 不区分可 null 与否!然后我发现这是因为没有完全重写,误会了 (??) operator 导致的一个设计问题…… 其实 deepDependencies 的基线完全可以是
[] 而非 null,手生了……
duangsuse::Echo
不是难看了一点,难看的东西都有问题! 我今天早上吃饭时想了一会,基本熟悉了它的工作方式: + no-dependencies = null + have-dependencies = each-dependency-with-their-dependencies ?? [itself] 后来我一想,不对啊 xs?.concat(x) ?? [x] 这不是等于 (xs ?? []).concat(x) 吗? 再一想,自己早在还没弄自动依赖解析之前就已经犯了这个错误,但那时候是情有可原,因为没 depend…
#JavaScript #Algorithm #web
而且我还想到一个问题,就是现在的依赖关系不能递归,但貌似我们拼接 Kotlin File 的方式是必须可以的,依赖不存在顺序。
或者说,我们要处理的『依赖图』,不一定是有向图,但目前的递归 deepDependencies 会 max call stack exceeded,我无法允许这种出错的可能。
所以可以用 DFS 啊,既然我们认为 a-b “a依赖b” 是互相的关系,那最终的完整依赖也可以视为一个集合,只需在添加 dependencySet 和 bfsQueue 前现判一下是不是已经有了就好了。
如 a-b 的循环依赖
此外,这两种(递归、BFS广度优先搜索)的依赖集合算法本身都是很泛化的『算法』,不该在某个特定的模块里针对特定抽象数据实现,可以抽象出关于类型
而且我还想到一个问题,就是现在的依赖关系不能递归,但貌似我们拼接 Kotlin File 的方式是必须可以的,依赖不存在顺序。
或者说,我们要处理的『依赖图』,不一定是有向图,但目前的递归 deepDependencies 会 max call stack exceeded,我无法允许这种出错的可能。
所以可以用 DFS 啊,既然我们认为 a-b “a依赖b” 是互相的关系,那最终的完整依赖也可以视为一个集合,只需在添加 dependencySet 和 bfsQueue 前现判一下是不是已经有了就好了。
如 a-b 的循环依赖
scan a -> add, queue b
scan b -> add, queue a
scan a -> continue
finish [a, b] 此外,这两种(递归、BFS广度优先搜索)的依赖集合算法本身都是很泛化的『算法』,不该在某个特定的模块里针对特定抽象数据实现,可以抽象出关于类型
<T> 的 deepDependencies(root: T, links: (T) => Iterable<T>): Array<T> 从而在更多数据结构上运行#TypeScript 的 overloads list 有点不直接,而且是半自动的多态…… 定义侧还得手动
typeof<script async src="https://cdnjs.cloudflare.com/ajax/libs/require.js/2.3.6/require.js" integrity="sha256-lIXwkX+X/PT2Ol6jZSAP/VfxI/RROCovmhrS4v1RrJs=" crossorigin="anonymous" data-main="dist/literate_kotlin_post.js"></script>SyntaxError: import declarations may only appear at top level of a module literate_kotlin_post.js:1
这是太蠢了! #web #JavaScript 不愧是前端『设计师』们的作品呢!
我都丝毫没有办法去手动给它加
type="module"当前端太困难了,我太难了,我想回去…… 还是写 Kotlin 好了,连个循环加载都做不到,import 居然能是『Statement』,各种 workaround,服了
不断地修改和抽提,也是我每写一个应用基本都会对应地弄出一个复用库的原因,所以我根本不愁写不出来『框架』,我写点应用都能写出『框架』来,只是时间真的不能保证……
duangsuse::Echo
乍一看大家会觉得它太冗了,虽然的确很冗,但具有可维护性、可扩展性,而且其复用可能性更大、给新人阅读理解也较容易。
看起来冗,但可以举个例子:如果要再兼容某个类似 KotlinPlaygound 的东西,要怎么样?
这个『冗长』 的版本只需修改 playgroundDefaults、literateCodeFilter、LiterateKtMagics.KotlinPlaygroundId 对应的几个逻辑就可以了,而如果写得更『精简』,没那么方便了。
再比如,很多本来可以通过面向对象继承提出的逻辑,如果不写『冗』一点,也是感受不出的。
再比如,如果你要写一个复用库,最好的方法就是边写边用!这时候没有『把结构写「复杂」』的觉悟,是很难完成同时编写应用和复用库的任务的。
总之,冗长的好处只有用过它的人才能完全体会得到。
那,如果模块化使得项目结构更复杂,让新人难以理解了怎么办???
所以要写好 README.md 啊…… 没人告诉我们,只有 project root 可以放 README 吧。
这个『冗长』 的版本只需修改 playgroundDefaults、literateCodeFilter、LiterateKtMagics.KotlinPlaygroundId 对应的几个逻辑就可以了,而如果写得更『精简』,没那么方便了。
再比如,很多本来可以通过面向对象继承提出的逻辑,如果不写『冗』一点,也是感受不出的。
再比如,如果你要写一个复用库,最好的方法就是边写边用!这时候没有『把结构写「复杂」』的觉悟,是很难完成同时编写应用和复用库的任务的。
总之,冗长的好处只有用过它的人才能完全体会得到。
那,如果模块化使得项目结构更复杂,让新人难以理解了怎么办???
所以要写好 README.md 啊…… 没人告诉我们,只有 project root 可以放 README 吧。
Forwarded from duangsuse Throws
#dev #PLT 给大家讲个有趣的事情:
🐔鸡你太美。
我在网易云音乐找这个东西的时候,对两首歌特别可心。
其一是原版《只因你太美》、其二是一个纯音乐 remix。
我们知道,原版(SWIN) 的是有歌词的(只因你太美……)
可是 remix 版只有重复的『鸡你太美……实在是太美』这样类似词穷的东西,我们认为它是纯音乐,没有唱词。
如果你是网易云的工程师,尝试用 #Kotlin 这样的『面向对象』编程语言给这样可能有歌词的歌曲建模,你会怎么建呢?
——
首先,我想到的办法是类似这样,
有点类似 libc 的『特殊返回值』,比如函数
但是这不是很规范,而且容易给数据维护制造问题,所以:
这样我们也可以同时表达有歌词的『只因你太美』和没歌词的『只因你太美(remix)』
可是,如果除了歌词外还有别的东西可能有出入,或者觉得『一首歌可能有歌词也可能完全没有、但居然还要存
🐔鸡你太美。
我在网易云音乐找这个东西的时候,对两首歌特别可心。
其一是原版《只因你太美》、其二是一个纯音乐 remix。
我们知道,原版(SWIN) 的是有歌词的(只因你太美……)
可是 remix 版只有重复的『鸡你太美……实在是太美』这样类似词穷的东西,我们认为它是纯音乐,没有唱词。
如果你是网易云的工程师,尝试用 #Kotlin 这样的『面向对象』编程语言给这样可能有歌词的歌曲建模,你会怎么建呢?
——
首先,我想到的办法是类似这样,
val NO_LYRICS: Lyrics = TODO()
data class Song(/*...*/, val lyrics: Lyrics)
比如,如果我们以链接(URI)的方式“存储”歌词,那么没歌词的情况:const val NO_LYRICS = "nolyrics:" 有点类似 libc 的『特殊返回值』,比如函数
ioctl 如果返回 (-1) 表示请求出错。但是这不是很规范,而且容易给数据维护制造问题,所以:
data class Song(/*...*/, val lyrics: Lyrics?) 这样我们也可以同时表达有歌词的『只因你太美』和没歌词的『只因你太美(remix)』
可是,如果除了歌词外还有别的东西可能有出入,或者觉得『一首歌可能有歌词也可能完全没有、但居然还要存
null』该如何?sealed class Music(/*...*/) {
data class Song(/*...*/, val lyrics: Lyrics): Music(/*...*/)
}
然后,我们在取的时候判断 music is Song,或者 (music as? Song)?.lyrics ?: "无歌词" 就可以了。