• @ruomu 可以的,我们同时也在招聘NodeJS的职位,我们主要看的是自学能力和态度,当前能力和经验都可以提高的。当然也希望在考虑应聘前,要对Ruby/ Rails和web开发的基础都有个熟悉。请投简历

  • 炮哥帮忙推荐下!

  • 这是一个例子,注意目录结构,外部的calendar.js里的这句话,会引用calendar/目录下index.js文件

  • @huacnlee 反向查询count时,如果之前没有请求一下Origin Object, 会导致Target Object xxx_by_users method undefined, 例如:

    #User Model
    action_store :star, :article, counter_cache: true, user_counter_cache: true
    
    #但是在测试里
    @article = create(:article)
    @article.star_by_users  #method missing error
    User #随便读一下user class
    @article.star_by_users # => []
    
  • 觉得CtrlP已经够用了,代码片段一边用ack-grep

  • 真要对比出来,可能要新开篇去说了。只能说下对于小公司来说,webpacker有点给我们带来这些好处: (1)以前前端同学写完后推代码,等运维同学拉代码部署到运行容器,接上数据查看有没出错,出错了还要重来一遍。现在直接本地可以同步效果,在同一个环境下不会再存在一些额外需要去把API服务器调跨域之类的问题。 (2) precompile后的工作和assets pipeline差不多,原来的部署脚本也一步到位了 (3) 像基本我们百分百对外项目静态文件都用到CDN的,用手动分离的方式中间要做很多的整合工作。 (4)和assets pipeline对比的优点就更不用说啦,yarn 对比gem,babel es6 es7 特性对比coffee,webpacker自带处理的各种vue-loader啊,portcss之类的,assets pipeline都会很别扭。

    综合地来说,就是对前端用得比较深的,都知道现在webpacker是大一统,前端最前沿的技术都在这里可以体验。assets pipeline和turbolinks是能顶大部分的需求,还是看项目情况使用吧。

  • 这种处理方式也是可行的。实际上我们现在一个在做的项目,已经会有多个分离出来的App入口,还有后台的前端部分也分离出来了,对于我们来说在webpack配置文件里做好入口判断会清晰点。

  • Rails里的webpack默认配置文件shared.js,是会把packs文件夹下根目录js文件都当作entry打包,会导致不必要的entry重复打包的问题。这里可以手动指定一下自己的entry,这样会大幅减少文件体积和提高打包速度。

    example:

    module.exports = {
      //手动指定两个入口
      entry: {
        'main': ["./app/javascript/packs/main"],
        'operate/main': ["./app/javascript/packs/operate/main"]
      },
      //下面是原来的配置
      //packPaths.reduce( 
        //(map, entry) => {
          //const localMap = map
          //const namespace = relative(join(paths.source, paths.entry), dirname(entry))
          //localMap[join(namespace, basename(entry, extname(entry)))] = resolve(entry)
          //return localMap
        //}, {}
      //),
    
      output: {
        filename: '[name].js',
        path: resolve(paths.output, paths.entry),
        publicPath
      },
    ........
    }
    
    
  • 更新了开发中遇到的一些小问题

  • 量产型炮灰工程师 at 2017年05月22日

    好文,观点都赞同