Discourse基础编辑器

是的,我最近一直在使用它来测试其他插件。如果你赶时间,可以观看我制作的视频,或者在本地安装并玩弄代码。我没有开源我开始开发的 tiptap 版本。我还致力于修复草稿系统。我认为关于一个人可以拥有多少草稿以及在哪里拥有草稿的规则感觉很随意。因此,用户可以拥有任意数量的新主题草稿。
但正如我所说,除非我真的非常无聊,否则我可能不会完成它,哈哈。
如果没有经济激励,我根本就不会太在意。

我也考虑过这个问题。我一直在研究 discourse-monero 集成,以便出售对 git 仓库的早期访问权限(也研究过将 discourse 与 gitea 或 gitlab 之类的东西集成)。但不确定是否真的有“人群”可以放入“众筹”中。似乎唯一为 discourse 付费的人是与 discourse 背后的公司有业务关系的人。

Tiptap 实际上并不是一个可比的例子,因为它只是使用 markdown 快捷方式转换为 HTML(据我所知)。您无法使用 markdown 编辑已存在的格式(因为语法不显示)。所以您可以单向进行,但不能反向。对我来说,任何不将输出渲染为 markdown 的 Discourse WYSIWYG 编辑器解决方案都是不可行的。这从根本上破坏了核心兼容性,并将您锁定在您选择的特定编辑器插件中。我想如果 Tiptap 可以输出到 markdown,那么这种方法就可以了。

展示 Typora 作为示例的重点是,它们以相当优雅的方式协调了 WYSIWYG 和 markdown。对于某些人,比如 @Jagster,保持现有行为而不必在预览和语法之间“跳转”似乎是可取的。但我确实认为 Typora 的方法对许多其他人来说更可取,也更直观。

听到这个消息真是令人兴奋!我肯定会对此感兴趣。

同意!我认为/希望这将在未来在核心中得到改进。

虽然我不认为您关于“唯一”为 Discourse 付费的人与 CDCK(Communiteq 可能会对此发表看法 :grinning_face_with_smiling_eyes:)有业务关系是完全正确的,但我确实同意,对于一个开源项目来说,Discourse 的社区在“社区精神”或“开放性”或类似方面有所欠缺。我无法确切地说出原因,但这里的事情肯定与许多其他开源项目不同,即使是那些由商业实体运营的项目。我希望真正的众筹努力和社区拥有/驱动的插件(甚至是对核心的更改)有一天能够实现。我特别希望看到这一点围绕主题开发,以实现更高级的布局和更改,正如我之前提到的:主题相对缺乏 - 我错过了什么吗?

4 个赞

我之前已经解释过我的立场。Markdown 是一种拐杖,我们需要摆脱它。

事实并非如此。如果有人真的想将 HTML 转换回 Markdown,他们可以做到并迁移回来。看看迁移脚本并编写自己的脚本。没什么大不了的。

说得有理。

主要问题是:不是用 react 编写的一切,现在都已经是沉没成本了。任何认真想在前端开发领域获得职业生涯的人,甚至只是想做一些有影响力的事情的人,都会避开非 react 的东西。
所以需要有经济激励来抵消这一点。开发人员体验也不是很好。与这个代码库一起工作并不真正有趣。所以,我继续从事这些事情的唯一原因,当我真的感到无聊时,是因为我已经投入了这么多时间并且已经习惯了它。:sweat_smile: :crazy_face: :slight_smile:

3 个赞

我认为,众筹对那些不是大型企业、不运行 Discourse 的个人来说会更容易。有一些社区贡献的插件和主题/主题组件。

非大型企业通常没有大量资金可以单独投资。但通过组织起来,社区资助的项目可以拥有相等甚至更大的资金池。

这只是一个如何申请的问题。无论是使用 Donate、Patreon 等。

是的,我认为您将编辑器现代化并使其非常用户友好的愿景对大众非常有吸引力。

3 个赞

我不同意,我到处都使用 Markdown,很高兴它存在并且得到了广泛支持。 :man_shrugging:

听到这个很有意思。我不是开发者,所以我不知道在 Discourse 代码库工作是什么样的。我希望你的经历不是常态,尽管我也认识到它的有效性和重要性。

3 个赞

这句话是否可以更好地表述为:任何想获得最多前端工作机会的人都应该学习 React?

我十多年来一直在生产环境中使用非 React 框架,从小项目到大项目,从全新项目到遗留项目。我曾在几个原型和玩具项目中尝试过 React,以了解它的工作原理。我目前的公司雇佣优秀的 JavaScript 开发人员,而不论其在特定框架方面的专业知识。

3 个赞

这可能会离题万里,但值得在某个地方讨论。

我认为,无论市场价值是否显而易见,如果有机会,学习各种语言和框架都是有益的,因为总有一些普遍适用的方法可以学习。此外,它也可能成为间接学习的途径。我最近学习了 Go 语言,以便在完全不同的平台上交付项目,这让我想起了简洁和速度的好处。我还学到了更多关于构建良好 API 的知识。如果我没有努力学习 Golang,我就不会有那样的经验。

Ember 是一个不容犯错但设计精良的框架吗?在 Discourse 上工作面临的挑战是,你还需要学习一个庞大的定制平台才能在其上游刃有余。在缺乏详细文档的情况下,你通过这种方式培养出的自力更生逆向工程方法,将在完全不同的领域中受益。

我认为学习一两个主要平台比学习特定框架更重要。例如,学习 Wordpress 是否比专注于学习 PHP 更重要?

所以,我认为学习不同的平台及其各自的技术栈不应该成为任何问题。然后,随之而来的是专业人脉的建立。所有这些经验的结合将为你的职业生涯打下坚实的基础。

我看到的主要问题是开源与资金之间的冲突。CDCK 本身就证明了围绕开源建立可持续的业务是可行的。我们必须变得相当成熟才能实现盈利并创造价值。

整个社区都有责任支持那些推动生态系统发展的人。我建议,这也始于社区将其自身平台货币化,以便他们能够负担得起贡献。许多人已经这样做了:我非常感谢在这里经常出现的、最有抱负和最勤奋的商界人士为我提供的资助工作。

10 个赞

问题在于:如果有人现在才开始,或者职业生涯还处于早期阶段,他们就会学习并专注于 React。专注于一项技术就像下注,而现在在前端押注任何非 React 的技术都是一个糟糕的选择。唯一合法的替代方案可能是 Vue,但肯定不是 Ember。
我认为,职业生涯专注于 Ember 的人数可能在很久以前就已经达到顶峰了。

你是否看到大量的人想学习 Ember 和 discourse 代码库?
我没有。这表明这是遗留软件。它已经达到了潜力的顶峰。没有大量的人想使用它或在其上工作。即使在远程工作和远程协作软件使用增加之后。人们更愿意使用 Zoom 和 Discord。

这就是我所说的开发者体验。

这是一个很好的观点。Discourse 主要是一个产品:一个为略显书呆子气的受众提供的自托管社区/支持论坛。它永远不会仅仅是这样,因为它的资金来源就是如此。所以大多数决定都将是为了取悦这个受众。
回到主题。替换 markdown composer 意味着让这个软件不那么书呆子气。所以它意味着与它所针对的受众产生分歧。
摆脱这个局部最优解并不容易。

所以一旦一个软件找到了它的受众,就会开始一个反射性反馈循环,导致更多的功能来取悦这个受众,而对其他群体的可用性却越来越被忽视。

4 个赞

我只是随便说说:

我们的论坛大约有 1000 名活跃用户,其中相当一部分是 50 岁以上的用户,他们都与 Markdown 相处融洽,而且我们从未收到过任何投诉。

我的看法是:如果一群吸毒者都能学会使用 Markdown,那任何人都可以。 :wink:

8 个赞

德国有 350 万大麻吸食者。84% 的德国人支持合法化。所以我认为你们的论坛有很大的增长空间。当前用户群及其潜在用户群相差数个数量级。仅仅通过小的改进或修改来朝着这个目标努力是远远不够的。

安抚当前用户群的改变甚至可能阻碍其增长。
改变总是需要权衡。让高级用户更方便的事情可能会让新用户望而却步。在某个时候,门槛会变得如此之高,以至于新注册用户枯竭,论坛会慢慢衰落。

3 个赞

你说得有道理。我们可能想调查一下(前)成员,找出他们离开我们论坛的原因。也许其中一些人实际上被 markdown 编辑器搞得不知所措了。

6 个赞

是的,这完全代表了我之前试图提出的关于 Meta 本身以及 CDCK 现有付费客户的回声室的一些观点。显然,您希望让现有客户满意,但也很明显,“社区/讨论平台”有一个更大的整体市场,由许多其他参与者提供服务,其中一些参与者肯定在做一些有助于他们达成交易而不是 Discourse 的事情。在我看来,其中一项可能是所见即所得,但这只是一个更广泛问题的一部分。整体设计和主题是另一个问题,我在上面已经提到过,但在这种独立的情况下值得重申:主题相对缺乏 - 我是不是错过了什么?

3 个赞

说得非常好。这只是冰山一角。有很多地方可以改进。例如,关于允许草稿数量的特殊规则。我最初以为这是一个错误,但实际上它是故意的。
我也试图解决这个问题。

5 个赞

你好,亲爱的开发者!

你在 2020 年 7 月写道:

那么它完成了吗?如果没有,请好心描述一下已知问题以及在第一个主题中该怎么做,以便 Discourse 社区管理员可以轻松决定是否使用它。

嘿 Spirobel,

请查看你在 WGMI 上的私信。

只是确保你收到消息。 谢谢!

3 个赞

别这么快放弃!我想我可以代表许多其他用户说,这个#plugin将是Discourse的绝对突破,并将改变一切,尤其是在某些用例中。我强烈鼓励你继续完成最后一步。:heartpulse:

你能详细说明一下吗?我可能需要它,所以我对你说的话非常感兴趣。你现在得到了我全部的关注……:eyes:

你不是一个人。看看这个话题。

6 个赞

:smiling_face_with_three_hearts: :smiling_face_with_three_hearts: :smiling_face_with_three_hearts:
我对此进行了更多思考。我认为替换编辑器不是一个好主意。因为这意味着将始终难以跟上 Discourse 的当前变化,而我不想花费如此多的时间来维护它。
我将利用我从中学到的知识,构建一个与 Discourse UI 并行工作的解决方案,而不是替换它。

11 个赞

如果它能解决现有编辑器的痛点,我也会很高兴。:grin:

4 个赞

@spirobel

我没有花太多时间研究它,但我想知道这个项目是否有助于在 Discourse 上实现一个友好的富文本编辑器:

你考虑过它吗?

谢谢!

7 个赞

是的,事实上我已经仔细看过并且会使用它。他们甚至将 excalidraw 集成了到编辑器中。这太棒了。我之前加入过他们的 discord 频道,讨论过一个与图片上传相关的问题。目前他们关于 excalidraw 的示例将图片嵌入为 SVG,这是一个安全隐患,需要进行更改。所以有一些小细节需要处理。

但与 ckeditor 或 tiptap 相比,它会容易得多。关于这个话题的总体情况也做一个简短的更新:

如前所述,修改 discourse 前端对于这种重大事项来说不是一个好主意。因此,将其作为传统界面的补充来实现此功能,而不是尝试替换它,是更好的方法。这里迄今为止获得的相关知识将用于:

虽然它面向 web3 用例并且会包含一些 web3 功能,但没有必要使用它们。

所以可以使用这个插件来创建具有词汇编辑器的类别。这也意味着尝试这样做风险要小得多。因为实验将仅限于网站的一部分。

我目前仍在忙于 discourse 的加密货币订阅工作。一旦完成,我将再次专注于推进此事。

6 个赞