We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
phoenix_live_view changelog
Welcome to the latest updates! We've been busy bees ๐, buzzing around and making improvements to enhance your experience with the Phoenix framework. Here's a rundown of the exciting changes and fixes we've implemented:
-
New feature: We've added a shiny new example to our documentation, showing off how to use dynamic components like a pro! Now you can see how to dynamically call a module and function using Elixir's
apply/3
. This example will have you rendering different outputs based on runtime conditions in no time! ๐ -
Improvement: Say goodbye to multiple
package.json
files! We've streamlined everything into a single file, making dependency management a breeze. Plus, we've given our ESLint configuration a makeover, ditching deprecated rules and adding cool new plugins for consistent coding. Your development experience just got a whole lot smoother! ๐ -
Improvement: Our LiveView JavaScript files got a little love, too! We've fine-tuned the logic for filtering components, ensuring only the relevant ones are processed. This means better performance and accuracy when handling components. We've also tidied up the
destroyHook
method for better readability. ๐งน -
Bugfix: We squashed a pesky bug in the
destroyHook
function that was causing hooks to be called more times than your alarm clock on a Monday morning. Now, hooks are properly cleared, ensuring a clean and error-free experience. ๐ -
Improvement: Our
attr/3
documentation got a boost with the addition of:fun
and{:fun, arity}
types. This makes it crystal clear how to specify function types when working with Phoenix components. ๐ -
Bugfix: We've scoped out the
findExistingParentCIDs
function to ensure it ignores CIDs in child LiveViews. This fix ensures updates aren't overlooked, keeping your LiveView components in tip-top shape. ๐ง
Enjoy these updates and keep on building amazing things with Phoenix! ๐
Included Commits
This commit consolidates the project structure by utilizing a single package.json
file, streamlining dependency management and build processes. The changes involve refactoring various test files to reference the new location of package.json
, as well as updating the ESLint configuration to remove deprecated rules and enhance code quality standards. The ESLint setup has been significantly expanded, incorporating new plugins and custom rules to enforce consistent coding practices across the codebase.
Additionally, the commit updates the CI/CD workflows to reflect the new structure and streamline npm commands, ensuring that tests and linting processes run smoothly. It also modifies several configuration files, such as Jest and GitHub Actions, to align with the new organizational structure. The README has been updated to simplify the instructions for running tests, making it easier for developers to get started with the project. Overall, this commit enhances maintainability and improves the development experience by centralizing configurations and dependencies.
Files changed
- .github/workflows/assets.yml
- .github/workflows/ci.yml
- .gitignore
- README.md
- assets/test/event_test.js
- assets/test/test_helpers.js
- assets/test/view_test.js
- babel.config.json
- eslint.config.mjs
- jest.config.js
- package-lock.json
- package.json
- priv/static/phoenix_live_view.cjs.js
- priv/static/phoenix_live_view.cjs.js.map
- priv/static/phoenix_live_view.esm.js
- priv/static/phoenix_live_view.esm.js.map
- priv/static/phoenix_live_view.js
- test/e2e/merge-coverage.mjs
The commit titled "properly scope findExistingParentCIDs" addresses an issue where the findExistingParentCIDs
function was not correctly ignoring component IDs (CIDs) in child LiveViews, which led to updates being overlooked in specific scenarios. The modification ensures that the function only considers CIDs within the same LiveView context, thereby preventing interference from child components. This fix resolves issue #3626.
Changes were made to the dom.js
file to refine the logic for filtering components, as well as to the dom_test.js
file to add a test case that verifies the new behavior. The test case demonstrates that the function now successfully ignores elements in child LiveViews, confirming the intended functionality of the fix. Overall, this commit enhances the robustness of the LiveView component management by ensuring proper scoping of CIDs.
Files changed
- assets/js/phoenix_live_view/dom.js
- assets/test/dom_test.js
This commit addresses an issue related to the management of view hooks in the Phoenix LiveView framework, specifically when destroying hooks. Previously, the destroyHook
function was clearing the hookId
from the element during destruction, which interfered with the cleanup process of the viewHooks
object. As a result, the hooks' destroy functions were being called multiple times, leading to potential inconsistencies and errors in the application. The fix involves retrieving the hookId
before it is cleared, ensuring that the appropriate hook can be removed from the viewHooks
object without duplication in the destroy process.
Additionally, the commit includes modifications to the test suite to verify the correct functionality of the hook destruction process. New assertions were added to ensure that the number of hooks in viewHooks
is accurate before and after updates, confirming that hooks are properly destroyed and cleaned up. Overall, this change enhances the reliability of hook management within the framework, preventing unnecessary multiple calls to the destroy functions and ensuring a cleaner state in the view's lifecycle.
Files changed
- assets/js/phoenix_live_view/view.js
- assets/test/view_test.js
This commit primarily focuses on updates to the phoenix_live_view
JavaScript files, making several modifications to improve the handling of LiveView components. Key changes include refining the logic for filtering components within the same LiveView, specifically by replacing a method that retrieves all child components with a more targeted approach that ensures only relevant components are processed. This change is reflected consistently across multiple files, including .cjs.js
, .esm.js
, and .min.js
versions, enhancing the efficiency and accuracy of component management.
Additionally, the commit introduces a minor adjustment in the destroyHook
method, where the identifier for the hook is now stored in a variable before being used for cleanup. This change not only simplifies the code but also improves readability. Overall, these updates aim to streamline the functionality of the LiveView framework, ensuring better performance and maintainability.
Files changed
- priv/static/phoenix_live_view.cjs.js
- priv/static/phoenix_live_view.cjs.js.map
- priv/static/phoenix_live_view.esm.js
- priv/static/phoenix_live_view.esm.js.map
- priv/static/phoenix_live_view.js
- priv/static/phoenix_live_view.min.js
This commit enhances the documentation for the attr/3
function in the Phoenix.Component
module by introducing the :fun
and {:fun, arity}
types. The addition clarifies that :fun
represents any function, while {:fun, arity}
specifies a function with a defined arity.
The modifications involve two new entries in the existing documentation table, ensuring that users of the Phoenix framework have a clearer understanding of how to specify function types when using the attr/3
function. This update improves the overall usability and comprehensibility of the API for developers working with Phoenix components.
Files changed
- lib/phoenix_component.ex
The commit titled "Add Dynamic Component Example to Documentation" introduces a new section in the Phoenix framework documentation, specifically focusing on dynamic component rendering. It provides a detailed example of how to use Elixir's apply/3
function to dynamically call a module and a function based on runtime conditions. The documentation outlines a dynamic_component
function that accepts a module and function as assigns, demonstrating how to pass shared attributes and slots to the dynamically invoked function.
The commit modifies the lib/phoenix_component.ex
file, adding 76 lines of content that include code snippets and explanations. It emphasizes the importance of defining the dynamic_component
with specific shared attributes and slots to maximize compile-time validation benefits. The provided example illustrates how to implement a dynamic component that can render different outputs based on the assigned module and function, enhancing the flexibility of component rendering within the Phoenix framework.
Files changed
- lib/phoenix_component.ex