模板迁移至react

[dongweiming]

我一直坚持做的东西要前瞻,跟上时代.

目前我们没有使用前端的开发框架. 近期我打算把react作为前端框架. 原因我来说一下:

1. react是目前最新最流行也是最适合IT同好的品味的东西, 而且facebook创造, 且有react native. - 假如用一个很low的框架, 未来第一是不好意思拿来做宣传, 二来容易被吐槽, 三用了react会让用户产生更多的好感
2. 豆瓣一些产品线已经在用, 包括我们组的一些功能使用了react, 暂时没遇到特别大的坑, 感觉挺好的 - 虽然我不是专业的大前端, 但是这些大前端的品味我们还是可以相信的

但是问题出现了:

1. 使用react会造成大量的前端代码放在jsx文件中, 就算放在模板中, plim对它的封装很少, 很有可能我们得给原项目提pr解决一些遇到的问题. plim的用途直线下降
2. 我最初使用plim其实有推广它, 变相支持它的意思. 但是渐渐的有一些理智和客观的看法, 假如我们该用前端框架之后, plim很难起到示范作用, 对于愿意尝试他的人来说, 需要首先对react有足够的了解. 其实react吧, 是一个在固有的逻辑思维的转化，我觉得有些人会直接放弃掉 - 不要太高估用户以及想了解他的人得精力能力以及毅力. 一个典型的例子就是vim和emacs. 假如完全么有用过编辑器,且对emacs没有特殊的害怕(被人说的很难, 会让人对他有敬畏感) 其实入门vim和emacs的没太大差别. 但是假如你习惯了vim再来学emacs(对, 我花了挺长时间去接受完全不一样的事物)
3. 我们使用plim的初衷最后会有怎么样的结果? 我担心最后我们做的这个事情反而是大家愿意看firelfy项目的阻碍, 也许有人不喜欢或者不想学习这个东西, 想要贡献还需要熟悉plim， 让一些人放弃,或者开始拖延. 对我们团队来说, 未来我们换(找)工作 熟悉plim可能没有什么帮助,当接受了一种思想, 一种习惯, 再去换jinja2或者其他会不会有些郁闷呢?

so. @mozillazg @halfcrazy 以及watch项目的同学们！问题来了.

大家觉得要不要用plim坚持下去, 还是换个更流行的jinja2或者mako. 甚至基于我们的需求前瞻性的用一个新的模板引擎

换模板是个非常痛苦的事情, 但是我担心我们下奶开始继续加功能, 对于未来是更大的负担.

希望大家有更多的想法,意见或者前瞻性的建议, 都可以说

[mozillazg]

plim 确实太小众了，而且它的思想跟主流的模板引擎还不一样导致项目的门槛变高了，感觉会让人望而却步。
个人推荐后端模板引擎改用 jinja2， 或者前后端完全分离？

[halfcrazy]

这里我倾向于前后端完全分离，模板就在前端做了。
理由的话，大概有两点：
1.现在的plim确实小众了点，之前用jinja2或者是ejs这种可能不太容易接受plim的语法
2.前后端完全分离的话，对于后期出app也有帮助

[halfcrazy]

再补充一点理由吧：
前后端分离，这样对于想加入的前端是非常友好的，只需要面向接口编程。如果有需要给个mock，也是可以脱离firefly的后端来开发的。

[dongweiming]

@halfcrazy @mozillazg 我们先确认下频道 - 说的前后端分离是指哪项:

1. VC用react来做, python只做M
2. react只做前端视觉交互, 抛弃python模板. 页面数据全部由json api返回
3. react只做前端视觉交互, 但是还使用jinja2模板做必要的地方数据, 业务数据通过json api返回

[mozillazg]

先 3 ？

• jinja2模板只提供基础数据：比如 topic 详情页面的当前 topic ID, 其他 topic 相关的信息通过 api 获取?
• 右上角的用户名之类的由 jinja2 模板渲染?

1跟其他2项之间的区别是什么？
2是指类似单页应用那种，使用前端 MVC 框架？

[dongweiming]

@mozillazg :

1和2的区别主要是路由在web后端用flask作 还是react-router来做;
2 就是不是一个接口的json返回，而更多的是多个接口返回, 比如获得current_user, 登陆状态之类也个页面都通用的数据是从另外一个独立的api拿到的 这样. 在后端就基本用不到模板了.

我个人也倾向于3.

[halfcrazy]

我也同意用3

[dongweiming]

目前觉得方案3只有一个弊端 就是未来的seo

爬虫如果不针对的爬 是爬不到内容的

[zbing3]

恩 倾向3 这样可以慢慢来了解react 我也更倾向于用jinja2

[dongweiming]

我建了一个react分支. 这个分支在替换完成后悔merge到master. 目前保持master不变(我会去guide里面做一些说明, 防止想贡献代码的人走了错的路线, 是不是也应该在master的README.md给个warning?)

这个分支主要完成2步:

1. 用jinja2替换掉plim. 主要是模板, 其次是views里面使用flask_mako的render_template等的mako用法
2. 对数据有变动的前端交互部分改装成react.

####目前在做第一部分, 完成情况如下:

1. 已经把react的js文件放到版本库, 配置能自动编译javascript/src下的jsx后缀的文件为js.
2. base.html/index.html/login.html以及markdown_editor.html中的创建新主题部分已经替换完毕. 同事删掉了topic.item.html. 大家其实可以参照修改的方式
3. 后端views主要是修改了home.py. 增加了2个model的接口(1. 获取当前所有的主题列表, 2渲染每个主题的原始数据. 修改的理由下面会说)

####还木有完成的:

模板方面

1. markdown_editor.html里面创建新回应的部分.
2. 键盘快捷键的modal模板 - widgets/keyboard.html
3. 分类列表模板 - categories/list.html
4. 单个主题模板 - posts/detail.html
5. 用户登陆页 - security/login_user.html
6. 用户信息模板(2个) - accounts/base.html/security/accounts/profile.html

视图方面.

1. category.py对应的修改. 我觉得和上面的模板3有直接的关系, 建议一起做.

PS:

1. 大家应该都使用libs/template.py里面的render_template 因为他会自动添加current_user. 当然未来可能会家更多的属性. url_for是flask默认就提供的.
2. views/api目录我感觉好像目前不受影响

[dongweiming]

大家可以继续讨论. 我来说说我的理解. 以及上面说的为什么做了以下事情:

1. 删除了topic.item.html
2. 给models/topic.py增加了get_all_posts和get_post这2个函数

第一个, 当时用它, 一是可以给首页的主题列表, 每个item都能使用它渲染. 也能通过这个函数在后端对于创建新主题加一个ajax的回调. 实现点击创建， 后端save了model之后会返回html让首页有新增新的item到首页的效果. 但是现在这个效果之后我想用react来做. 来扩展

这就是涉及到了什么时候应该用react, 什么时候直接在后端用jinja2写模板?的问题

react是为了解决复杂的页面交互的问题. 我觉得会变的部分应该让react组件化, 未来由前端进来 也好扩展 而不用了解后端技术. 举一些例子.

1. 首页点开, 渲染第一页的主题列表, 我觉得直接用模板渲染就好. 几个原因吧. 第一是假如都安排给前端, 让前端js调接口, 返回再渲染, 把这活留给了客户端, 肯定没有后端直接渲染的好. 其次是seo. 第三点是我们这是python社区， 我还是希望给python工程师留下很多机会. 但是新建的一个item会浮出来，是页面的动态交互, 应该给react， 后期还会有类似websocket从后端获取最新的items. 比如一个页面打开了就去做别的了, 这个时间里面有别人的点开了并且发布了新的主题, 我们再打开那个一直闲置的页面的时候, 应该有个有xx个新主题的提示, 也是react组件一起做的事情
2. 比如我们的注册页面, 这个应该整体react来控制, 比如验证密码长度了, 邮箱地址格式了这些东西, 不需要到后端 前端就能做一些甄别了.
3. 单个主题页的交互要更多, 比如我点进去会列出已经有的评论的列表, 这个模板直接渲染, 但是我点击喜欢/收藏/查看某个回复下有什么对应的回复这些都应该react来做.

第二个, 其实大家已经有了统一的认识 - 前后端分离。 我们从长远看, 要为未来写移动app接口做好准备, 提前预留. 上面也说了, react太重了 这就不怎么像python社区了. 及比如目前react-china.org用ember.js写的是最大的槽点.

我最大的担心来着seo. 我们这种小站， 像大百度大google这样的公司肯定不会对我们定制, 假如一些结果都用api返回，js来处理, 一般的爬虫是爬不到结果的. 对于我们社区被搜索到这件事有很大的影响. 问题是我门早期还是希望搜索引擎给我们带来各种的量的. 我之前也研究过seo. 当我们的网站因为被爬不到数据而只抓到基本的html且这种基础的html不变化的话, 会被搜索引擎降级. 他会觉得你的网站是一个更新很少的网站, 会造成爬取网站的时候越来越长. 对我们的长久发展不利

所以我加了2个方法. 一方面这样的meta数据一方面可以被web端用, 一方面未来app端用的话也差不了多少 基本能用.

[dongweiming]

等白天我会更新下未做的部分到trello. 大家可以认领. 我也会逐渐的列出来第二步的一些方案. 我还是会先给大家做例子.

然后我再去更新下guide和README

[halfcrazy]

SEO 见http://www.ruanyifeng.com/blog/2011/03/url_hash.html
Google抓取#的机制
默认情况下，Google的网络蜘蛛忽视URL的#部分。
但是，Google还规定，如果你希望Ajax生成的内容被浏览引擎读取，那么URL中可以使用"#!"，Google会自动将其后面的内容转成查询字符串_escaped_fragment_的值。
比如，Google发现新版twitter的URL如下：
　　http://twitter.com/#!/username
就会自动抓取另一个URL：
　　http://twitter.com/?_escaped_fragment_=/username
通过这种机制，Google就可以索引动态的Ajax内容。

[seozed]

Google 的方案不适用于baidu，而且因为墙的原因，目前Google search 在中国大陆基本上没有份额了。如果网站的主要目标群体是在国内的话，用Ajax的渲染需要做特殊处理，见百度官方这篇文档，http://zhanzhang.baidu.com/college/articleinfo?id=294

[halfcrazy]

@qsnow6 学习了

[halfcrazy]

@qsnow6 新发现一个东西 https://prerender.io/

[guyskk]

我写的框架，为restful api 而生
https://github.com/guyskk/flask-restaction
希望能有所帮助

前后端分离好处多多，SEO不难解决，我同时在做一个多人博客系统
https://github.com/guyskk/kkblog

SEO问题我的解决办法
https://github.com/guyskk/kkblog#前端

[hns007]

这个项目停了吗?发现代码已经6个月每更新了

[junnplus]

@hns007 项目应该是没有停，只是暂时搁浅了，应该是的

引用 @dongweiming 说的

我个人在做一个python的社区 firefly. 未来会一直坚持下去

[zbing3]

是的 现在明哥 一直在弄code 估计弄到一个满意的版本 就应该再开发 firefly了

在 2015年12月28日 上午10:38，Nplus Jun notifications@github.com写道：

@hns007 https://github.com/hns007 项目应该是没有停，只是暂时搁浅了，应该是的

引用 @dongweiming https://github.com/dongweiming 说的

我个人在做一个python的社区 firefly. 未来会一直坚持下去

—
Reply to this email directly or view it on GitHub
#92 (comment).

[junnplus]

@zbing3 开发 firefly 并不能只靠 @dongweiming ，毕竟这是社区，而开发任务的认领机制我觉得有点杂乱

[dongweiming]

@junnplus @zbing3 sorry 上段时间CODE开源了, 还没来得及继续CODE的下一步, 最近一直忙于年底的工作. 我也在写书. 能力和精力都有限, firefly就一直没有动静

现在firefly最大的问题是前端架构能能力, 我们也缺少这方便的童鞋. 最近我也小参与了豆瓣的各种榜单工作, 都是react做的, 收获很多.

这个项目肯定会继续走下去. 但是最近确实没有时间. 在停止firefly的时候就曾经在slack里面周知大家原因.

[dongweiming]

大家有兴趣又能力可以继续走着. 不用等我, 有想法和思路的 都可以在这里继续讨论