写在前面
他的来源是什么
他能做什么
演示一下？
-
我自己也试了一下他的功能，使用起来是比较简单的，可以像使用 jQuery 一样的方式直接引入 CDN 或者是 npm i 安装也是可以的，那么之后我们就可以直接在 html 中使用他的语法了
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>测试 htmx 的用法</title> <script src="./js/htmx@1.9.5htmx.min.js" integrity="sha384-xcuj3WpfgjlKF+FXhSQFQ0ZNr39ln+hwjN3npfM9VBnUskLolQAcN80McRIVOPuO" crossorigin="anonymous"></script> </head> <body> <script type="text/javascript"> // const baseGetRequest = 'http://jsonplaceholder.typicode.com/users' // window.baseGet = baseGetRequest </script> <!-- 测试基础的 get 请求 --> <div hx-get="http://jsonplaceholder.typicode.com/users"> Put To Messages </div> <!-- 测试基础的 post 请求 并将请求的结果给到另一个 span 的元素上 --> <div hx-post="http://jsonplaceholder.typicode.com/posts/1/comments" hx-target='#aimDiv'>测试一条数据</div> <span id="aimDiv"></span> <!-- 模拟一个对话框的请求 --> <button hx-get="http://jsonplaceholder.typicode.com/users" hx-confirm="Are you sure you wish to delete your account?"> Delete My Account </button> <!-- 测试一个 boost 的请求 --> <div hx-boost="true"> <a href="http://jsonplaceholder.typicode.com/users">Blog</a> </div> <!-- 测试一个表单 --> <div id="search-results"></div> <form action="/search" method="POST"> <input class="form-control" type="search" name="search" placeholder="Begin typing to search users..." hx-post="http://jsonplaceholder.typicode.com/posts/1/comments" hx-trigger="keyup changed delay:500ms, search" hx-target="#search-results" hx-indicator=".htmx-indicator"> </form> <!-- 测试 table --> <input class="form-control" type="search" name="search" placeholder="Begin Typing To Search Users..." hx-post="http://jsonplaceholder.typicode.com/posts/1/comments" hx-trigger="keyup changed delay:500ms, search" hx-target="#search-results" hx-indicator=".htmx-indicator"> <table class="table"> <thead> <tr> <th>First Name</th> <th>Last Name</th> <th>Email</th> </tr> </thead> <tbody id="search-results"> </tbody> </table> </body> </html>- 上面那段代码执行结果如图：
它提供了哪些便利
- 请求不需要封装函数
- 防抖节流直接通过属性进行配置
- 请求方式直接通过属性进行配置
- 回参渲染到某个元素可以指定
- 指定的方式很多（css 选择器、元素选择器等）
- 局部内容替换成本很低
- 前端代码量极少
- 浏览器渲染速度很快
他有哪些劣势
- 项目体量不可以过大，这样对服务器的压力太大
- 过于复杂的操作不太可行，毕竟他都是通过配置的，配置就意味着定制化的需求满足程度不会太高
- 过于依赖服务器，前端只是进行配置
- 对Django的依赖也比较大，因为他就是配合他用的（这里我也问了一下我身边使用Django的朋友，他给的回复是：jango 内置了 web 开发工具，可以用 {} 直接获取 response 对象属性。在前后端不分离年代还是挺厉害。现在不行了）