---
title: Arez 0.119 released
author: Arez Project
authorURL: https://github.com/arez
---

[Full Changelog](https://github.com/arez/arez/compare/v0.118...v0.119)

Changes in this release:

* **\[core\]** Remove the concept of environments from within Arez. It was primarily used as a mechanism
  for integrating with external frameworks with their own scheduler so that context can be introduced around
  reactions, tasks and actions. The best example was integration with [React4j](https://react4j.github.io/)
  that ensured that the top level task within Arez was wrapped within a `batchedUpdates(...)` wrapper
  method which avoided repeated re-rendering of components. React has subsequently made batching automatic
  for event handlers and within the normal rendering lifecycles and optional in other scenarios
  (i.e. network events triggering changes etc.) with the goal of ultimately deprecating and removing the method
  when concurrent react is activated. As a result the conceptual overhead, maintenance costs and slight code size
  increase no longer seems a reasonable tradeoff within Arez and has been removed until it is actually needed.
* **\[core\]** Make the `arez.SchedulerLock` class public and change the return type of the
  `ArezContext.pauseScheduler()` to be `ScheulerLock`. This does not change the functionality exposed but instead
  ensures that the method returns an object with a more easily understandable purpose.
* **\[core\]** Rename the `Executor.AREZ` enum to `Executor.INTERNAL` and the `Executor.APPLICATION` enum
  to `Executor.EXTERNAL` to reflect actual semantics.
* **\[core\]** Change the mechanisms via which test utility `arez.ArezTestUtil` resets state so that zones and
  zone stacks are not created if zones are disabled. Nor is a non-Zoned context created if zones are enabled.
* **\[core\]** The `ArezTestUtil.resetState()` method was made private and instead it is automatically invoked
  when configuration settings are modified that needs a state reset.
* **\[core\]** Fixed a bug where actions invoked from within a `Zone` where the action is part of a different
  `Zone` did not correctly activate and deactivate the zone to which it was associated with over the scope of
  the execution. Thus any call to `Arez.context()` would return the incorrect context and thus components created
  within the action were associated with the incorrect zone. A similar bug was present in externally executed
  observe methods.

Update site to add news about the 0.119 release
Update site to add news about the 0.119 release
