Release packages [publish docs]

[imodeljs-admin]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to master, this PR will be updated.

Releases

@itwin/presentation-hierarchies@1.3.0

Minor Changes

• #783: Extended createPredicateBasedHierarchyDefinition props to accept HierarchyDefinition functions: parseNode, preProcessNode and postProcessNode.

  The change allows creating a fully capable HierarchyDefinition with all the custom behaviors provided by those functions.

• #791: Unify hierarchy updates' handling.

  Previously, we'd only raise the HierarchyProvider.hierarchyChanged event on data source changes. The tree state hooks would listen to this event and trigger a hierarchy update. However, there are a few other reasons for the hierarchy to change - changing formatter or active hierarchy filter. In those situations the event was not raised, but tree state hooks still had to trigger hierarchy update. So we ended up with a mix of event-driven and manual hierarchy updates.

  With this change we're clearly stating that a hierarchy provider should trigger its hierarchyChanged event whenever something happens that causes the hierarchy to change. That means, the event will be raised when formatter or hierarchy filter is set, and tree state hooks can initiate hierarchy reload from a single place - the hierarchyChanged event listener.

  To let event listeners know what caused the hierarchy change, the event now has event arguments, which should be set by the hierarchy provider when raising the event. This allows listeners to customize hierarchy reload logic - for example, our tree state hooks always keep existing tree state except when a new hierarchy filter is set, in which case the existing state is discarded.

• #783: Added hierarchy filtering helper to make hierarchy filtering easier to implement.

  The helper can be created using the createHierarchyFilteringHelper function and supplying it the root level filtering paths and parent node. From there, filtering information for specific hierarchy level is determined and an object with the following attributes is returned:

  • hasFilter tells if the hierarchy level has a filter applied.
  • hasFilterTargetAncestor tells if there's a filter target ancestor node up in the hierarchy.
  • getChildNodeFilteringIdentifiers() returns an array of hierarchy node identifiers that apply specifically for this hierarchy level.
  • createChildNodeProps() and createChildNodePropsAsync() return attributes that should be applied to nodes in filtered hierarchy levels, after applying the filter.

  See the Implementing hierarchy filtering support learning page for a usage example.

  In addition, deprecated a few APIs that are replaced by filtering helper:

  • extractFilteringProps function,
  • HierarchyNodeFilteringProps.create function.

Patch Changes

• Updated dependencies:
  • @itwin/presentation-shared@1.2.0

@itwin/presentation-hierarchies-react@1.2.0

Minor Changes

• #791: Unify hierarchy updates' handling.

  Previously, we'd only raise the HierarchyProvider.hierarchyChanged event on data source changes. The tree state hooks would listen to this event and trigger a hierarchy update. However, there are a few other reasons for the hierarchy to change - changing formatter or active hierarchy filter. In those situations the event was not raised, but tree state hooks still had to trigger hierarchy update. So we ended up with a mix of event-driven and manual hierarchy updates.

  With this change we're clearly stating that a hierarchy provider should trigger its hierarchyChanged event whenever something happens that causes the hierarchy to change. That means, the event will be raised when formatter or hierarchy filter is set, and tree state hooks can initiate hierarchy reload from a single place - the hierarchyChanged event listener.

  To let event listeners know what caused the hierarchy change, the event now has event arguments, which should be set by the hierarchy provider when raising the event. This allows listeners to customize hierarchy reload logic - for example, our tree state hooks always keep existing tree state except when a new hierarchy filter is set, in which case the existing state is discarded.

Patch Changes

• #786: Bump package dependencies.
• Updated dependencies:
  • @itwin/presentation-shared@1.2.0
  • @itwin/presentation-hierarchies@1.3.0
  • @itwin/unified-selection@1.1.2

@itwin/presentation-shared@1.2.0

Minor Changes

• #791: Added a number of mapped types:

  • Props<TFunc> obtains the type of the first TFunc function argument.

    function func(props: { x: number; y: string }) {
      // ...
    }
    type FunctionProps = Props<typeof func>; // { x: number, y: string }

  • EventListener<TEvent> obtains the event listener type of given event type.

    type MyEvent = Event<(arg: number) => void>;
    type MyEventListener = EventListener<MyEvent>; // (arg: number) => void

  • EventArgs<TEvent> obtains the type of the first event listener's argument of given event type.

    type MyEvent = Event<(arg: { x: number; y: string }) => void>;
    type MyEventArgs = EventArgs<MyEvent>; // { x: number, y: string }

@itwin/presentation-components@5.6.1

Patch Changes

• #786: Bump package dependencies.

@itwin/presentation-core-interop@1.1.2

Patch Changes

• Updated dependencies:
  • @itwin/presentation-shared@1.2.0

@itwin/presentation-testing@5.1.2

Patch Changes

• Updated dependencies:
  • @itwin/presentation-components@5.6.1

@itwin/unified-selection@1.1.2

Patch Changes

• Updated dependencies:
  • @itwin/presentation-shared@1.2.0

[github-actions[bot]]

Hierarchies benchmark

Benchmark suite	Current: 2173887972fc5ef80e9bf53cd1304390a55d8c36	Previous: a9a4a0cd121f09d4ab42402c1b7f36e6c145c7a3	Deviation	Status
flat 50k elements list	4729.17 ms	4775.55 ms	-0.9712%	✅
flat 50k elements list (P95 of main thread blocks)	77 ms	74 ms	4.0541%	🚨
filtering filters with 50000 paths	10492.45 ms	10743.93 ms	-2.3407%	✅
filtering filters with 50000 paths (P95 of main thread blocks)	119 ms	124 ms	-4.0323%	✅
grouping by label	10840.56 ms	11108.54 ms	-2.4124%	✅
grouping by label (P95 of main thread blocks)	64 ms	66 ms	-3.0303%	✅
grouping by class	10843.97 ms	11119.33 ms	-2.4764%	✅
grouping by class (P95 of main thread blocks)	51 ms	38 ms	34.2105%	🚨
grouping by property	11627.38 ms	11872.35 ms	-2.0634%	✅
grouping by property (P95 of main thread blocks)	75 ms	55 ms	36.3636%	🚨
grouping by base class (10 classes)	8584.87 ms	8759.87 ms	-1.9977%	✅
grouping by base class (10 classes) (P95 of main thread blocks)	74 ms	76 ms	-2.6316%	✅
grouping by multiple attributes	28527.71 ms	29404.77 ms	-2.9827%	✅
grouping by multiple attributes (P95 of main thread blocks)	46 ms	42 ms	9.5238%	🚨
hide if no children required to finalize root, w/o children	51827.27 ms	55043.06 ms	-5.8423%	✅
hide if no children required to finalize root, w/o children (P95 of main thread blocks)	38 ms	30 ms	26.6667%	🚨
hide if no children required to finalize root, w/ children	177.56 ms	175.83 ms	0.9839%	🚨
hide if no children required to finalize root, w/ children (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨
models tree initial (Baytown)	40.6 ms	43.87 ms	-7.4538%	✅
models tree initial (Baytown) (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨
models tree full (Baytown)	8323.2 ms	8764.83 ms	-5.0387%	✅
models tree full (Baytown) (P95 of main thread blocks)	85 ms	87 ms	-2.2989%	✅
models tree creates initial filtered view for 50k target items	2419.38 ms	2298.8 ms	5.2453%	🚨
models tree creates initial filtered view for 50k target items (P95 of main thread blocks)	735 ms	370 ms	98.6486%	🚨

This comment was automatically generated by workflow using github-action-benchmark.

[github-actions[bot]]

Unified selection benchmark

Benchmark suite	Current: 2173887972fc5ef80e9bf53cd1304390a55d8c36	Previous: a9a4a0cd121f09d4ab42402c1b7f36e6c145c7a3	Deviation	Status
hilite 50k elements	1195.75 ms	1226.86 ms	-2.5357%	✅
hilite 50k elements (P95 of main thread blocks)	51 ms	44 ms	15.9091%	🚨
hilite 50k group elements	231.09 ms	249.64 ms	-7.4307%	✅
hilite 50k group elements (P95 of main thread blocks)	31 ms	31 ms	0%	🟰
hilite 1k subjects	45754.61 ms	44967.25 ms	1.7510%	🚨
hilite 1k subjects (P95 of main thread blocks)	29 ms	30 ms	-3.3333%	✅
hilite 50k subcategories	269.26 ms	267.88 ms	0.5152%	🚨
hilite 50k subcategories (P95 of main thread blocks)	32 ms	33 ms	-3.0303%	✅
hilite 50k functional 3D elements	28317.61 ms	28358.75 ms	-0.1451%	✅
hilite 50k functional 3D elements (P95 of main thread blocks)	39 ms	41 ms	-4.8780%	✅
hilite 50k functional 2D elements	6536.87 ms	6477.68 ms	0.9138%	🚨
hilite 50k functional 2D elements (P95 of main thread blocks)	31 ms	36 ms	-13.8889%	✅
compute selection for 50k elements	331.67 ms	339.37 ms	-2.2689%	✅
compute selection for 50k elements (P95 of main thread blocks)	35 ms	35 ms	0%	🟰
compute parent selection for 50k elements	338.56 ms	332.81 ms	1.7277%	🚨
compute parent selection for 50k elements (P95 of main thread blocks)	31 ms	31 ms	0%	🟰
compute top ancestor selection for 50k elements	565.41 ms	558.91 ms	1.1630%	🚨
compute top ancestor selection for 50k elements (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨
compute category selection for 50k elements	87 ms	97.76 ms	-11.0065%	✅
compute category selection for 50k elements (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨
compute model selection for 50k elements	69.64 ms	68.31 ms	1.9470%	🚨
compute model selection for 50k elements (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨
compute functional selection for 50k 3D elements	401.47 ms	398.32 ms	0.7908%	🚨
compute functional selection for 50k 3D elements (P95 of main thread blocks)	31 ms	31 ms	0%	🟰
compute parent functional selection for 50k 3D elements	443.67 ms	429.44 ms	3.3136%	🚨
compute parent functional selection for 50k 3D elements (P95 of main thread blocks)	31 ms	31 ms	0%	🟰
compute top ancestor functional selection for 50k 3D elements	1179.26 ms	1144.39 ms	3.0470%	🚨
compute top ancestor functional selection for 50k 3D elements (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨
compute functional selection for 50k 2D elements	3040.84 ms	2933.22 ms	3.6690%	🚨
compute functional selection for 50k 2D elements (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨
compute parent functional selection for 50k 2D elements	3065.68 ms	2947.89 ms	3.9957%	🚨
compute parent functional selection for 50k 2D elements (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨
compute top ancestor functional selection for 50k 2D elements	3075.35 ms	3018.93 ms	1.8689%	🚨
compute top ancestor functional selection for 50k 2D elements (P95 of main thread blocks)	0 ms	0 ms	NaN%	🚨

This comment was automatically generated by workflow using github-action-benchmark.