Wijmo 5.20241.9: CollectionView and Partial

Posted by: mark.brodziak on 3 April 2024, 10:08 am EST

  • Posted 3 April 2024, 10:08 am EST

    Dear Mescius,

    Can you please provide some guidance for how we should deal with the type changes in the latest Wijmo release?

    The release announcement (https://developer.mescius.com/blogs/wijmo-2024-v1-has-landed?utm_medium=Release&utm_source=Email&utm_campaign=wijmo-2024-v1) mentions:

    Implemented enhanced type validation for generics in CollectionView, requiring TypeScript users to review and correct mistyped CollectionViews for improved code integrity. Some customers might see errors at compile time that can be easily corrected by attributing correct types.

    So, changes here are not unexpected. However, there doesn’t seem to be any associated documentation on the types, or WHY the CollectionView now deals with Partial in several places - most pressingly for us, on CollectionView.sourceCollection. The documentation on https://developer.mescius.com/wijmo/api/classes/Wijmo.Collectionview.html#sourcecollection doesn’t give us any hints.

    Can you explain why the collection view exposes values as partials?

  • Posted 5 April 2024, 12:49 am EST

    Hi Mark,

    I have requested the Dev team to provide more details regarding the partial type change with an internal tracking ID WJM-33681. We will provide you with an update as soon as we hear back from them.

    Regards

  • Posted 10 April 2024, 11:39 pm EST

    Hi Mark,

    Did you find any solution to this issue with Partial. I have upgraded to latest version of wijmo in my angular app, and facing the similar issue.

  • Posted 12 April 2024, 12:02 am EST

    Hi,

    Could you please share some more details about the issue you are facing, so that we can provide you a solution accordingly? Please share a small sample in which the issue can be replicated so that we can have a better understanding of the issue.

    You can also modify the attached sample to replicate the issue and share it with us.

    Regards

    FlexGrid_angular_sample.zip

  • Posted 15 April 2024, 11:12 am EST

    Hi @latha7art,

    We don’t really have a ‘solution’ so much as to do a blind cast, right now, because the type seems bogus.

    @Vivek, do we really need to provide a code sample to ask for the API to be properly documented?

    As an extremely simple and contrived example, let’s suppose we have:

    interface Point {
      x: number;
      y: number;
    }
    
    ...
    
    const collectionView: wj.CollectionView<Point>
    
    ...
    
    // Wijmo declares this to return (Partial<Point> | Point)[] so this assignment fails
    const  values: Point[] = collectionView.sourceCollection; 

    Why, if a CollectionView is defined with type T, does Wijmo decide that everything within it is now a partial? That means that we may not have any defined property. This seems quite counter-intuitive and the reasoning is undocumented.

  • Posted 16 April 2024, 8:55 pm EST

    Hi Mark,

    We have an update from the dev team, i.e. Partial type was added as a proactive approach to handle scenarios where the returned objects from CollectionView may not always guarantee that all fields will be present and may contain undefined values.

    By using Partial, the intent is to signal to the consumer function that the object can be partially filled, and it should perform null checks or handle potential undefined values accordingly.

    So, in the code snippet you shared, you’ll need to define the type for ‘values’ as ‘Point | Partial’, as per the current CollectionView structure, i.e.

    const values: Point[] | Partial<Point>[] = this.data.sourceCollection;

    Regards

  • Posted 17 April 2024, 1:55 pm EST

    Right, but can you provide any transparency into why these would be Partial?

  • Posted 19 April 2024, 8:19 pm EST

    We’ve just been hit by the same issue - the updates are welcome but the timing could have been better :slight_smile:

    In our case we ended up writing a utility function whose only purpose is to cast in a safe-ish way whenever we want access to the source collection (a non-Partial array almost all of the time for us)

       /**
         * Return a strongly typed array underpinning a collectionview
         * @param collectionView
         * @constructor
         */
        public SourceArray<T>(
            collectionView: ICollectionView<T> | ICollectionView<Partial<T>>
        ): Array<T> {
            return collectionView.sourceCollection as Array<T>;
        }

    and we just grab and operate on the return value.

    I work on the assumption the actual calls will be optimised away in any case.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels