# \[Pre-ANN/RFC\] ExpandNestedData.jl (Previously Normalize.jl)

**URL:** <https://discourse.julialang.org/t/pre-ann-rfc-expandnesteddata-jl-previously-normalize-jl/91015>\
**Category:** Package Announcements\
**Created:** [November 29, 2022, 10:22pm UTC](https://discourse.julialang.org/t/pre-ann-rfc-expandnesteddata-jl-previously-normalize-jl/91015 "2022-11-29T22:22:47Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [December 1, 2022, 9:37am UTC](https://discourse.julialang.org/t/pre-ann-rfc-expandnesteddata-jl-previously-normalize-jl/91015/21 "2022-12-01T09:37:47Z")

</div>

> [@mrufsvold](#):
>
> I love the idea. Is it sufficient to return  
> \<…\>  
> And let a user format that as StructArrays or whatever they’d like. Or is it better to add StructArrays as a dependency and do that formatting for automatically?

I believe there are no existing functions that convert this “nested namedtuple” of columns into different table types. Meanwhile, various tables support this conversion with exactly the same syntax, but the table constructor has to be inserted at each level:

```julia
T(
    d = [4,4,4,4],
    a = T(
        b=[1, 2, [3,4], []],
        c=[2, missing, 1, missing]
    )
)

```

works equally well for a range of table types, such as `T = StructArray` or `T = Table` (from `TypedTables.jl`).

---

<div class="post-metadata">

**Author:** ![mrufsvold](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mrufsvold/32/31600_2.png) [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)\
**Post date:** [December 7, 2022, 9:01pm UTC](https://discourse.julialang.org/t/pre-ann-rfc-expandnesteddata-jl-previously-normalize-jl/91015/22 "2022-12-07T21:01:08Z")

</div>

Thanks again, everyone, for your feedback!

I’ve updated the project to [ExpandNestedData.jl](https://github.com/mrufsvold/ExpandNestedData.jl). And the main function to `expand`. Thanks @Dan.

Per @aplavin’s suggestion, I added an option for users to choose `flat_columns` or `nested_columns`. If you choose `nested_columns` it returns a TypedTable with the columns nested matching the hierarchy of the source data. I know it is idiomatic to accept `Symbol`s for this kind of paramater, but I made an enum, `ColumnStyle` that gets exported because I like the built-in protections of the type system. Should I revert this decision and just use Symbols?

Long term, I’ve considered making a custom Table.jl type that is nested internally, but you can access the columns as flat or nested. But I don’t have the bandwidth right now to implement the whole interface, so I’m going to lean on TypedTables for now 🙂

I still haven’t decided on what the interface for a `compress` function would look like. I need to experiment a bit before trying to publish a feature. But I added it to the roadmap. @quinnj’s `Strapping.jl` seems to be pretty much filling the need for that utility. I am considering pulling in `Strapping.jl` as a dep and having `compress` take a Table and some `ColumnDefinition`s and use those to build `StructTypes` that would drive `Strapping.construct`. But that’s tentative.

I’ll post another ANN once I’ve got something workable and register the package.

Thanks again!

[Previous page](https://discourse.julialang.org/t/pre-ann-rfc-expandnesteddata-jl-previously-normalize-jl/91015.md?page=1)