Shopify 前端开发经验总结（问题及解决）

最新推荐文章于 2024-03-18 13:41:12 发布

学海里的小码农

最新推荐文章于 2024-03-18 13:41:12 发布

阅读量3.5k

点赞数 4

分类专栏： shopify 文章标签：前端 javascript html5

本文链接：https://blog.csdn.net/weixin_54515240/article/details/126661447

版权

shopify 专栏收录该内容

7 篇文章 2 订阅

订阅专栏

对shopify的理解：（个人理解不具有权威性，若有错欢迎指出，非常感谢）

shopify其实就是一个为跨界电商准备的售卖网站，与其他淘宝和京东非常相似，但是对于商家来说，可能更具有个性化，我没有做过淘宝等网站的项目，不过我的理解是这些网站对于卖家来说可能结构和产品展示形式都是已经定下来的，商家只能把产品放在上面展示，由于结构和功能其实都是淘宝定义好的，所以没有什么修改的权限，只能说投放产品罢了，但是shopify更具有针对性，比较适合开发独立的品牌，结构和展示形式更具有个性化，（以下内容是我的猜测）但是shopify的后台功能是写死的，应该是不能够自主添加了，也就是说，shopify在电商卖家提供了包括交易、购物车、注册、等等与后台数据相关联的功能性都帮电商写好了，对于前端来说，其实并没有特别大的影响，前端只负责修改页面和样式相关的内容。功能已经写好了，因为我看shopify出的也比较早最早在2006年由加拿大5人创建直至2019年的不断壮大完善，已经有了较为完整的后台系统，前端只需要关注页面层即可，而且shopify其实具有非常多的可用模板，应该是有人专门制作模板的类似于ppt模板等供商家选择，不过这类产品的可能是收费的，而且只要是购买模板的情况下是很难做到个性化，毕竟已经模板化了，所以shopify前端开发的主要职责相关还是与模板相关，也就是制作商家满意的前端展示形式。

对于编辑者模式下的理解：

对于这个编辑者模式，我一开始有着非常大的误解，我甚至一度觉得是多此一举既然有预览模式了，要编辑者模式干嘛？后面才发现大错特错，之前有谈到shopify有较为完善后台系统，但是后台数据终究要与前端结构样式相结合才是最终呈现给用户的样子，而这个编辑者模式下就相当于将数据放进已完成的框架中进行展示，也就是是可以理解成，编辑者模式其实就是商家操作数据的地方，比如一个轮播图前端结构样式功能都完成了，只需要数据即可驱动，这时候就需要在编辑者模式下进行数据的填充，这就相当于是shopify的后台部分了，商家在开发过程中也会成编辑者模式下的操作为后台操作，与我传统理解的后台操作还是有区别的，我一开始以为后台是关于见表写数据库相关的，因为shopify已经写好了，所以后台对数据的操作可以通过一些可视化的操作进行，编辑者模式下是一种，应该有数据相关联比如产品和产品之间的关系一个有另外的操作渠道，我目前不太清楚。

对于Liquid的理解：

对于liquid的理解，在初学的时候我也存在一定的误解，我以为是背弃html和css等原规则有一些新的规则，因为我看到文件结构是.liquid结尾，其实是大错特错了，其实liquid只是方便了html的div的展示，相当于可以在div层面进行一些if判断语句等等操作，其实和vue很像就是在原有的html基础上丰富了很多原先在div内部其实不能进行的一些操作，其实完全可以将liquid理解成vue一样，其实不止不会背弃原有的html和css而是强化他的功能，所以我对liquid的理解也对我开发起到了很关键的作用，由于我在公司是一个人做前端，遇到问题是通过微信请教其他人（公司提供的大佬），所以大多数问题会走很多弯路，比如我一开始在创建block的时候，是使用js的手段创建的，看我之前的分享也可以看得出，我先在js里面for block in blocks获取到编辑者模式下创建的block个数然后通过js插入div结构到页面中，这是一个非常愚蠢的行为，而且会造成比较严重的后果，接下来我会就我犯过的错误进行讲解为什么不能这样做。

！！！！重点：（我认为较为有用，我犯过错误，但是并不是所有人都会这么笨，给和我一样想歪的的一些tips）

首先，尽量避免js去创建dom元素，原因很简单，也避免js去修改与页面展示相关的后台数据比如调节间距等，为什么呢？其实是这样的，我们在学基础的时候都知道，页面是先有dom元素的生成，才能去操作dom元素的，如果js去生成dom元素会造成什么后果呢？就是我们的商家也就是商店管理员在编辑者模式下是无法查看到生成的dom元素的，也就是在编辑者模式下无法实时查看添加商品或者修改样式后的样子，虽然在预览模式下也会看得到，不会影响用户的体验，但是这大大影响了商家的使用体验，不可能她想看修改后的结构还要到预览模式下去查看吧，肯定是需要一个实时的反馈效果才对，如果你通过js去创建dom就很有可能会导致这种情况的产生，至于是为什么，我曾经有做过测试，编辑者模式下并不一定会加载某部分js，也就是说在编辑则模式下section的js不一定执行，这也是为什么我们theme.js明明引入就JQuery代码但是你在section中去使用他显示未定义的一个主要原因，因为在编辑者模式下theme.js是执行的所以在编辑者模式下shopify一些自带的功能比如轮播图是能够实时显示的，和预览模式下页面效果一样，但是theme.js是应该有过延迟加载一样的操作，可能是避免商家用户卡顿吧，因为可能有些js是去到预览模式下才会执行的，这时候你先预览一下，再回到编辑者模式下其实很多section的js也会执行，但是我们不能这样去要求用户，尽量避免这种操作的产生，其实shopify也考虑到了这种情况，所以引入了liquid语法，帮助我们解决这种问题，就比如很多时候例如轮播图他是不确定的dom数量，所以通过for block in blocks 去动态创建dom结构，生成对应的数量，这样既可以在编辑者模式下产生，也无需依赖js，其实引入liquid的目的就是解决这类问题的，我属实是反向操作，明明可以一步解决非要绕几步，相信大多人都是聪明的不会犯这种错误，我也是有点迷迷糊糊，是在学的前几天犯的错误。

接下来我会把我犯错的笔记以及解决问题的笔记放在下面：（如果有遇到同样问题，却看不懂我笔记写的什么可以问我，我详细解答，因为我写的可能只有自己看得懂）

利用for block创建的元素，能够通过$jQuery操作元素嘛？是元素先创建还是js先执行-------------------------待测试

解决：能够操作，那么应该是原生div>liquid的div>js

问题：gallery的小li互相干扰

解决：修复了小li互相干扰的bug，原因：其实不单单需要修改小li的class，并且需要修改小li的控件，也就是是loopli，不然会互相干扰，shopify的section中jQuery能够拿到所有section的变量，而不是一个section就真的是一个页面，在一个首页部分，都能拿到数据，section可以理解成一个个组件，之间的变量命名还是不能一样会互相干扰。

滑动改变position

bug：slishow按钮自动变到最大，设置min-width失败，设置max-width有效但是无法实现效果

解决：将按钮设置成inline-block，之前设置的是block，block默认的宽度是100%所以导致设置min-width失效，其实就是block设置了width，转而设置inline-block就不会有默认宽度了，可以解决问题。

页面：404原因是由于编辑者模式下未删除对应section的情况下就去暴力删除section文件了，导致报错解决：①去index.json里面删除已经删除的section②或者还原被删除文件，先在编辑者模式下删除section再去删除section

bug：在js里面使用

liquid语句，无法生效

解决方法：不要陷入思维误区，js有自己的判断语句，逻辑功能并不会比liquid的差，所以完全没有必要纠结用liquid实现，大可以直接写js判断语句或条件判断，不过需要注意字符

这里就是我上述提到的我在js创建元素添加到div中，属实是南辕北辙了。

少了''这个符号就是变量了，会报错

在liquid代码上面使用js语法命名变量可能会触发报错，并且不生效，但是如果加上；号就会运行成功，具体原因不详。

还与console.log有关，如果不console.log不加；也不会报错，但是如果有了console必须加；

我找到原因了：放进for的变量必须加；符号，否则就会报错，反正加了就不会报错，但是只是在$符号里面的话不会报错，我猜测可能是$封装脱离了liquid限制。内部的变量最好也加；无脑加就完了

js中的for语句如果有变量，需要在他头上声明一遍才能使用，不然会丢失最初声明命名的那个值

问题：product页面无法跳转bug且出现404页面

问题解决：404问题一般都是json出问题了，我看了一下，好像之前图片格式删除了，但是json为改动，导致图片格式依旧存在与product.json格式里面导致无法跳转，删除即可

问题：为什么避免本地修改编辑者模式呢？因为本地修改的是临时的，重启cmd后会复原至你拉下云端主题的json

解决：因为本地修改的话，如果删除会导致json文件丢失，因为编辑者模式下可以理解成后台模式下编辑，你拉下来的主题的时候 json已经定死了，所以你继续删除或者修改涉及json数据的时候，他是无法监测到的，下一次cmd启动的时候，系统就会报错，告诉你json数据丢失原因也很简单，就是修改后的模板部分json已经丢失了或者说被你删除了，但是拉下的json是死的，所以他会认为文件是丢失的而不是你删除的，避免这种情况也非常简单，就是在云端商店的编辑者模式下进行操作，这样改变的数据就是后台的，而cmd条件下编辑的数据在下一次重启的时候会复原成拉下来最初的样式的，也就是json在拉下来的时候已经定死了，虽然cmd条件下依旧可以进行修改也能够显示，但是不会修改json的数据，json在拉下来那一刻就已经定死了，不会实时监测，可以选择手动修改修复bug，但是shopify不会帮你在json中删除的。

shopify特点：

编辑者模式下是先未进行section的js运行，只会进行theme.js的运行，不过一旦进入预览模式下，section的js运行会快于theme.js

作者和logo标签，需求是作者名字不定，随着名字变长，logo变短

实现思路：将一行内的盒子，父盒子设置flex，剩下子盒子中需要变化的设置display：inline-block，图标盒子按要求给width就好了，然后右侧被挤压的盒子先设置最大宽度，width：200px等随着第一个盒子变大他会自动被挤压

注意点：第一个盒子不要设置最小宽度，不然会导致文字压住右侧盒子，理解来说就是，变化盒子不给宽度，被挤压盒子给最大宽度②注意添加不换行符号white-space: nowrap;

实现参考代码：

</head><body>

123456

<div class="son2">
  <img src="./images/a34982b8-280b-4851-b162-e4255bc64312.png" alt="">
</div>
<div class="line">

</div> </div>

问题：鼠标悬停修改图片问题

解决：其实block中的数据确实没法在js中获取，但是可以将数据存储到界面中，因为其实liquid的代码都是结构相关的代码，所以可以存贮到对应的样式里面，然后通过display：none将结构隐藏，但是依旧可以通过js获取代码中的数据，然后拿到需要的数据，就非常方便修改数据了，主要是拿数据的思路，不是直接从block中获取，而是js获取dom元素获取，然后修改图片问题归根结底还是修改

问题：无法获取同类名元素的自定义属性

解决：代码使用不正确

错误代码如下：每次获取的都是一个class的自定义属性

正确代码：

之前是以为$(".here").attr("data-index")就能获取到不同的index，其实他一直都是获取第一个的，所以错误了。

正确思路应该是与鼠标事件相关联，这样获取到的每一个here都是鼠标悬停的位置也就不会出现index都是同一个的情况了，思路就是同一类名但是只能鼠标在的时候变化的就和鼠标相联系。

html格式损坏的原因：基本是少了某些结构例如div等等，需要自行盘查，可能是本来粘贴赋值过来的时候漏了或者多了，也可能是if语句等liquid判断语句放的位置不佳导致的。

修改样式不生效，或者页面元素丢失

当修改这里页面元素才能显示，但是去代码中修改对应样式依旧无法生效，最大可能是多了}花括号在上面，导致样式失效,这个是非常低级的错误，当时困扰了很久不知道为什么多出这个bug，其实就是在css部分修改样式的上面部分多打了个}导致下面的样式不生效，如果你也是修改图中部分样式发现变化，但是在文件里面修改css无法改变可能是这个原因

bug：Test模块点击左右键会跳转至product页面，原因就是原功能在布局的时候加了两个a标签，但是只为第一个a标签进行收尾处理，第二个没有导致这个bug，在button前为第二个a标签收尾即可。

修改url失效的原因：很大一部分可能是因为修改的时候拿到的只是图片的地址并非图片的url，console保证拿到的是url（”“）且内部为字符串才能展示出来