Alt text
Alt text网上关于在GitHub上打造高星项目的经验分享不多，少数几篇也是巨牛级别的，让人学习起来无从下手。所以我想把这次有意思的经验写下来和大家分享。
Lepton介绍
Alt text
Alt text Alt text代码分行
如上图，代码块放在了一个HTML table中。首先用正则式/\r?\n/
把代码分行，并同时计算每行对应的line number。line number放在上面HTML Table中的第一列，代码放在第二列。使用Table的好处是，当某行代码太长导致一行放不下而被迫折返时，它不会进入line number的列中。下面是不使用Table时可能会遇到的问题。
Alt text
不要复制line number
有时候，我们在网上复制代码时，会碰到误选line number，导致如下图中line number也一同被复制的现象。
Alt text
Lepton的解决方案是采用data-pseudo-content
来标记行数，避免了line number被误选复制的问题，效果妥妥的！
Alt text
React + Redux state
开始时，我曾把一些Dialog的show/hide作为React component的local state来处理。当时我认为它们和app的全局state无关，应该放在component中。后来，随着dialog数目的增多（search/create/edit/delete/logout），属于不同component的dialog出现了相互覆盖、难以协调的现象。最后我不得不把它们改回全局的redux state。这是一点小经验。
标签实现
GitHub Gist本身不支持标签。我一开始想法是通过一个secret gist来保存和同步标签。后来发现这个方法有些问题。
效率不高，每次标签变化都要把所有标签记录重新写入这个secret gist，而且出错后容易丢失记录，最后弃用。
开发者不应该在没有得到用户同意的情况下，私自使用secret gist来存储数据。任何关于gist的改动都应有用户来做决定。
目前方法是通过description部分的特殊字符#tags
来保存自定义的标签。优点是标签分散到每个gist中，每次只需要更新该gist对应部分的标签即可，可以同步到云端。而且它可读性高，即使用户有一天抛弃Lepton转回原生的网页端，也能轻易读懂description的信息。
Alt text
UI设计
图标
Alt text
Alt text Alt text后续思考
毫无疑问，这是一个很有趣的经历，不仅仅是积累了很多技术（在开发Lepton过程中，我自己就使用Lepton记录了大量的gist），还在产品上有了更多的思考。
项目开发前两周，我所有注意力都集中到集成GitHub API、完成基本的CRUD功能上，我所关注的是HOW。当进入第四周到第五周，产品核心功能（Tag + Search + CRUD）逐步完善，受到关注越来越多，我更多思考这个项目是什么（WHAT）。我是要把GitHub自带的Gist网页端复制到桌面吗？还是通过Lepton自建一个snippet生态？我们应该如何取舍平衡功能呢？
我的结论是，Lepton要成为能保存代码的印象笔记，姑且理解为“印象代码”。它的终极目的是以开源本身来回馈开源社区；它的直接手段是帮助程序员有效利用收集的点滴智慧（读作dai ma），在抱StackOverflow大腿之余，也能够抱自己大腿。所以，我在新功能的取舍上以下面“三个有利于”作为衡量标准：
是否有利于用户收集代码 （比如引入CodeMirror）
是否有利于用户便捷获取代码 （比如引入Local Search、copy/share button）
是否有利于用户专心分析代码 （比如 Immersive mode）
并且在社区的帮助以及自己时间允许范围内进行。
最后，Lepton这段经历告诉我们，打造一个GitHub上千星项目，过程其实没有那么神秘，重点在于清晰的项目目标和乐于分享的精神。
一点意外的是，有人想到了把Lepton作为一款支持markdown的轻量级“印象笔记”来使用。