V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
tu7jako
V2EX  ›  前端开发

前端页面设计模式求救

  •  
  •   tu7jako · 137 天前 via iPhone · 3800 次点击
    这是一个创建于 137 天前的主题,其中的信息可能已经有所发展或是发生改变。
    vue 前端有多个页面,整体界面及其相近,只有少数内容不同….目前想采用模板设计模式开发。但具体怎么写没谱,想求 v 友分享案例~~谢谢了
    45 条回复    2024-07-11 10:03:32 +08:00
    iOCZS
        1
    iOCZS  
       137 天前   ❤️ 5
    用组件是基本操作,你想在更高层次复用的话,未必必要。越通用的东西越复杂,毕竟要支持各种情况。
    heybwei
        2
    heybwei  
       137 天前   ❤️ 2
    1 楼说的对,越通用越复杂。并且需求有时候真的说变就变,你能保证后续需求不会破坏了你的模板设计逻辑吗?

    我曾经封装过一个用户/群组选择的弹窗组件,后续因为不同场景去适配各种模式:不同模式有可能同个接口,定制筛选要求,不同空间的权限要求等等。给后面接手的同学造成很大压力(界面还是这个界面,但是变动的小的功能点不同模式下不一样)。
    oxAlex
        3
    oxAlex  
       137 天前 via Android   ❤️ 3
    简单的事情切勿复杂化
    ivslyyy
        4
    ivslyyy  
       137 天前   ❤️ 2
    vue slot 了解一下
    nitmali
        5
    nitmali  
       137 天前
    相同的部分抽出来做成组件,差异部分做成 props
    douxc
        6
    douxc  
       137 天前
    赞同 1 楼
    klo424
        7
    klo424  
       137 天前
    没必要,真没必要,还不如复制粘贴来的快而稳。
    tu7jako
        8
    tu7jako  
    OP
       137 天前 via iPhone
    好吧~听劝放弃
    Jinxishihenian
        9
    Jinxishihenian  
       137 天前
    ColdBird
        10
    ColdBird  
       137 天前
    别把暂时的相似当作永久的通用,不然后面通用模板里塞一推业务逻辑,最后变成屎山
    dfkjgklfdjg
        11
    dfkjgklfdjg  
       137 天前
    封装真正通用的部分,可自定义的部分可以用 slot ,用这样的方式来设计一个自定义组件就好了。
    如果不是状态类型的差异不建议使用 props 来传递。

    最后就是如果是一个表单组件,如果只是部分表单内容不一致,可以把表单拆开成多个自定义表单组件,然后在各自的页面引用就好了。
    而不会推荐你去封装一个大的自定义表单组件,然后用 slot/props 去传递差异的 form-item 。
    MRG0
        12
    MRG0  
       137 天前
    复制粘贴
    gzyguy
        13
    gzyguy  
       137 天前
    稳通用的写成组件模板,对可能变化的地方做插槽处理。如果不确定,谨慎写成组件,否则后面组件内部一堆 props 和 if else 。
    K332
        14
    K332  
       137 天前
    复制粘贴呀,这个很简单吧,不用考虑什么复用
    okrfuse
        15
    okrfuse  
       137 天前
    封装成组件,加 slot ,时间允许可以尝试写一下,不写永远不会进步,时间不允许,复制粘贴是王道
    ryougifujino
        16
    ryougifujino  
       137 天前
    首先你说只有少数不同,那就采用模板的模式,把变化的部分采用 render prop/slot 的模式来处理,切忌直接在模板里用 if else 。

    如果页面只有部分相同,这时候就不适合用模板了,最好是每个页面独立出来,只把相同的部分抽象成组件。

    还有一个复用层面是逻辑相同,但是 UI 有所差别,这时候就是用 hooks/composition api 的时候了。
    hxysnail
        17
    hxysnail  
       137 天前
    居然都说复制粘贴好,前端都这个水平吗……

    拿我们的前端来说,同个东西,在不同页面都有不同的风格和行为,不就是因为复制粘贴来的吗……一个设计良好的系统,好多通用改动,本来在框架或者模板层面动一下就解决了。结果因为复制粘贴多了,改动扩散到好好多个页面,然后 TMD 还改漏了……

    设计模式是个好东西,结果因为自己驾驭不了就说复制粘贴好,就没人怀疑过自己的认知吗……
    zhtyytg
        18
    zhtyytg  
       137 天前
    @hxysnail 屁股决定脑袋。如果你做过的项目普遍需求稳定排期合适,那么一定会偏向于高度封装。反之,你就会理解屎山代码的出现原因。
    zhuangzhuang1988
        19
    zhuangzhuang1988  
       137 天前
    可以看下
    React 开发人员 dan abramov 得文章,有时候复制粘贴也是一种好模式
    https://overreacted.io/goodbye-clean-code/
    leon233333
        20
    leon233333  
       137 天前
    能抽出来一些还是抽出来一些,不然复制粘贴改相同代码的时候容易漏掉
    finalwave
        21
    finalwave  
       137 天前
    @hxysnail 有合格的产品和设计才有合理的前端组件设计。动不动就加两个改两个需求,不去复制粘贴,那组件的可维护性更是灾难。
    RogerL
        22
    RogerL  
       136 天前
    我习惯用 hooks 抽象出数据,然后样式数据分离
    比如 useTable 这种,传入一个 request ,返回 dataSource ,pageInfo ,isLoaing
    大部分情况下,数据逻辑其实是差不多的(基本就返回数据,loading 加载状态,分页这几个)
    UI 如果真的差距比较小,你就可以继续封装成更通用的
    fuyun
        23
    fuyun  
       136 天前
    @hxysnail 因为:1 、目前绝大多数项目都是短平快的复制粘贴项目,只要求“可用”,不要求“优雅”; 2 、目前很大部分前端确实不需要、不了解、不会设计模式,都用 vue 了,还谈设计模式?
    weixind
        24
    weixind  
       136 天前
    这种场景下,组合优于继承。理解这个了就知道应该怎么搞了。使用插槽是个糟糕的设计。
    chicbian
        25
    chicbian  
       136 天前
    尽量的细化组件,先写几个页面,然后再抽,基本上你就知道要抽那些了,逐渐的抽离。本人站 vue ,写这种非常丝滑。只封装最基本的组件,然后基于这个,封装上层业务组件。
    lizy0329
        26
    lizy0329  
       136 天前
    简单封装一下即可,前端页面过时得非常快
    hxysnail
        27
    hxysnail  
       136 天前
    @zhtyytg 其实问题是出在人的能力上,能力已经具备的前提下,高度封装是本能,肯定是比简单复制粘贴高效的。但是很多人把能力建设的时间算在项目排期上,因为他不会,而学习需要时间,但学习其实是在学校阶段就要做的事情。
    hxysnail
        28
    hxysnail  
       136 天前
    @fuyun 虽然我也不用 vue ,也更喜欢 react 的设计理念,但是我不认为 vue 就不配谈设计模式。其实,再烂的语言,都有漂亮的写法。前端项目短平快是现状,现状不意味着正确。
    hxysnail
        29
    hxysnail  
       136 天前
    @finalwave 我觉得这是另一个问题,不能因为别人烂我跟着烂吧……实际上,好的设计适应性也强,更不会因为产品设计的调整就大动干戈。
    fuyun
        30
    fuyun  
       136 天前
    @hxysnail 不是不配,只是现状下选择的最优解。而且,设计模式是有成本的,jQuery 也可以撸一个优雅的方案出来,但大部分情况下你还是会选择框架。同理,大部分公司、项目就是为了解决实际问题的,甚至还要求快,这也是为何很多人倾向于 vue 的原因。另外,自己的项目大多是 ng 路线……
    X0V0X
        31
    X0V0X  
       136 天前 via iPhone
    复制粘贴,早点下班
    zhtyytg
        32
    zhtyytg  
       136 天前
    @hxysnail 你这就属于话不投机半句多了。我完全赞成#21 楼说的,并且认为你有点想当然的俯视本帖下的所有人。你能力这么出众,应该已经财富自由了吧?
    hxysnail
        33
    hxysnail  
       136 天前
    @zhtyytg 话不投机不要说不就完了嘛?非要说那么多干嘛呢?我是不是可以学你这么说:

    既然复制粘贴这么牛逼,你也掌握了这个大招,在前端圈应该混得风生水起,财富自由了吧?相反,我由于没理解到复制粘贴的精髓,所以混了这么多年,还在苦哈哈打着工,有上顿没下顿的。是否有什么书讲解这个技巧的,不凡告知小弟,我想学习一下,
    daysv
        34
    daysv  
       136 天前
    没啥设计的, 全走函数完事。react 你想怎么拆就怎么拆
    asdjgfr
        35
    asdjgfr  
       136 天前
    业务搞封装就是屎山,这是无数前辈总结的经验,跟语言、框架都没关系
    gerefoxing
        36
    gerefoxing  
       136 天前
    不要封装,业务页面以后会出来个性化需求的,公用封装以后一堆判断,每个页面自己写自己功能模块就行了。除非那种非业务的公用的,这些可以封装下组件
    LeeSeoung
        37
    LeeSeoung  
       136 天前
    mixin 合理复用就行了。
    cheneydog
        38
    cheneydog  
       136 天前
    相同的且通用部分抽出来做成组件,差异部分做成 props 。
    也同意以上回答,不要过度封装业务。业务如果理解的很深可以按照业务抽象组件,但是拿捏不好业务还是按技术通用部分抽出来做成组件,哪怕业务实现上啰嗦重复。
    Yumwey
        39
    Yumwey  
       136 天前
    做过一个通用卡片设计,最早规划就是后端数据动态渲染卡片效果,后来全部变成定制了😂
    ZGame
        40
    ZGame  
       136 天前
    @heybwei 看看复杂度 哈哈
    JamesFisher
        41
    JamesFisher  
       136 天前
    接手过一个资深前端的代码,整个路由视图被封装成了一个组件,调用这个组件得传二十几个参数,且参数之间互有依赖,由于没有文档,光熟悉怎么传参就花了一周。后续要增加一些小功能也不得不在这个通用组件上改,直叫人心死头秃。

    封装组件,一开始可能边界清晰,功能内聚,随着功能的变化,它对外界的接口会越来越不清晰,使用它的成本越来越大,对后续接手的人就是史诗级别的灾难
    yangzzzzzz
        42
    yangzzzzzz  
       136 天前
    封装组件没难度。还是看以后需求会不会频繁变动,评估下需求有没有必要封装,经常变动的页面真不如复制粘贴省事
    xcccer
        43
    xcccer  
       136 天前
    @gerefoxing 学习了
    zogwosh
        44
    zogwosh  
       136 天前
    只复用逻辑,不复用视图,
    只复用逻辑,不复用视图,
    只复用逻辑,不复用视图,
    只复用逻辑,不复用视图,
    违反这一点的代码都是在挖坑
    unco020511
        45
    unco020511  
       136 天前
    相同部分用组件,内部的不同部分可以插槽 slot ,逻辑单独的文件复用
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2669 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 03:17 · PVG 11:17 · LAX 19:17 · JFK 22:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.