标签： Lighthouse 5
-
本文介绍了在 Laravel 6 和 Lighthouse 5 环境中，实现验证输入值组合是否存在的方法。文章首先定义了 GraphQL Schema，接着在自定义验证器类中编写了相应的代码逻辑。测试结果显示请求验证失败符合预期，且最终确认生成的 SQL 语句验证规则正确。
-
本文分析了主题编辑器页面保存后与实际页面不一致的问题，指出快速编辑时，后端保存接口从 Redis 读取数据的时机早于暂存接口写入数据的时机，导致数据未同步。最初尝试后端计数等待方案，但因存在数据丢失风险，最终参考 Shopify 实现，改为基于 hashValue 的比对机制。该方案在暂存和保存时分别计算与比对哈希值，仅在一致或用户确认忽略冲突时执行保存，从而有效解决了并发请求下的数据一致性问题。
-
本文探讨了在 Laravel 6 结合 Lighthouse 5 环境中，invoke 魔术方法的 $args 参数内部顺序与前端请求参数不一致的问题。经测试发现，直接转换 $args 或通过 Illuminate\Http\Request 获取请求参数，字段排序均会发生变化，而通过获取请求体的原始内容，则能确保与前端顺序完全一致，从而解决了字段顺序错位的问题。
-
本文针对 Lighthouse 中 resolver 对应的类方法 __invoke 未执行的问题进行排查。通过打印日志和调试调用栈确认构造函数正常执行但 __invoke 未被调用。对比其他正常执行的 resolver 类，发现调整 GraphQL 架构定义或解析类可恢复执行。最终定位问题根源在于该类方法内部使用了 yield 循环，删除后 __invoke 即可正常执行。
-
文章解决 Laravel 6 结合 Lighthouse 5 和 nwidart/laravel-modules 7 使用时出现的容器绑定解析异常。排查过程包括修改 GraphQL 文件、检查解析器构造函数及服务提供者注册，并通过调整模块目录名和执行 Composer 安装进行测试。最终发现服务提供者虽实现延迟加载接口但未实现 provides 方法，导致服务未在缓存中正确注册，删除延迟加载实现后程序恢复正常运行。
-
在 Laravel 6 和 Lighthouse 5 环境下，使用 @rules 指令应用 exists 验证规则时，自定义属性名无法按语言区域正确翻译，导致返回的验证消息中包含原始字段名而非本地化名称。经过排查，排除了 nwidart/laravel-modules 版本及语言文件位置的影响，确认原因在于 Lighthouse 5 对验证属性的支持不够彻底。目前决定暂不编写自定义验证器类，暂时接受在非英语环境下属性名未被完全翻译的现状。
-
针对在 Laravel 6、LightHouse 5 和 PHPUnit 环境中编写 Mutation 测试时需要删除缓存数据的需求，文章参考了 REST API 测试中先操作数据库再请求删除的思路。通过调整测试策略，先直接操作缓存生成明确的缓存标识，随后执行 HTTP API 请求进行删除操作。实际运行结果显示，该方案成功通过测试，实现了对删除缓存标识 Mutation 的有效验证。
-
本文介绍了在 Laravel 6 结合 Lighthouse 5 及模块化架构下，为 GraphQL API 创建自定义验证规则的过程。通过在模块中生成规则类，编写逻辑判断缓存标识是否存在，并在 Schema 文件中使用 @rules 指令引用该规则，实现了验证逻辑的复用。文章还详细说明了如何配置模块内的多语言文件以返回本地化错误消息，最终完成了包含中英文错误提示的接口功能测试。
-
文章记录了在 Lighthouse 5 中基于 PHPUnit 编写 Mutation 测试的过程。通过编辑 GraphQL 测试文件解决了输入类型报错问题，并针对因请求参数重复导致验证失败的断言错误，将变量 key 的值改为基于时间戳生成。该方法在配置单独测试数据库的基础上，有效避免了多次运行测试时的参数冲突，确保了测试结果的稳定性。
-
在编写 Lighthouse 5 的自动化测试用例时，PhpStorm 无法自动完成且无法找到 assertJson 方法的声明。经排查，这是因为 nuwave/lighthouse v5.36.0 与 Laravel Framework 6.20.44 版本不匹配，导致对象路径异常。通过 Composer 将 nuwave/lighthouse 回退至 ~4.10.1 版本后，PhpStorm 恢复了代码自动完成功能，问题得到解决。