How to organize exports?

Question
1

I have saw patterns like that,but don’t quite understand.Basically I would like to aggregate methods of multiple objects into one,how to do that ?

      object bundle
    // Attrs
    extends Attrs[Attr]
    with AriaAttrs[Attr]
    // Event Props
    with ClipboardEventProps[EventProp]
    with ErrorEventProps[EventProp]
    with FormEventProps[EventProp]
    with KeyboardEventProps[EventProp]
    with MediaEventProps[EventProp]
    with MiscellaneousEventProps[EventProp]
    with MouseEventProps[EventProp]
    with WindowOnlyEventProps[EventProp]
    // Props
    with Props[Prop]
    // Reflected Attrs
    with ReflectedAttrs[ReflectedAttr]
    // Styles
    with Styles[StyleSetter]
    with Styles2[StyleSetter]
    // Tags
    with DocumentTags[ReactiveTag]
    with EmbedTags[ReactiveTag]
    with FormTags[ReactiveTag]
    with GroupingTags[ReactiveTag]
    with MiscTags[ReactiveTag]
    with SectionTags[ReactiveTag]
    with TableTags[ReactiveTag]
    with TextTags[ReactiveTag]
    // Builders
    with CanonicalAttrBuilder
    with CanonicalReflectedAttrBuilder
    with CanonicalEventPropBuilder[dom.Event]
    with CanonicalPropBuilder
    with ReactiveTagBuilder
    with SetterBuilders[ReactiveNode, dom.Element, dom.Node]
    // Other things
    with DomApi
    with Implicits {

    val focus: FocusReceiver.type = FocusReceiver

    val child: ChildReceiver.type = ChildReceiver

    val maybeChild: MaybeChildReceiver.type = MaybeChildReceiver

    val children: ChildrenReceiver.type = ChildrenReceiver
  }
2

Are you familiar with how traits work? This is basically just taking a zillion traits, each of which deals with one specific problem, and sticking them all together into a single object.

3

They’re all defining a subset of an API. They aren’t separate problems at
all. I think for something like the DOM this is reasonable.

4

Well, ‘separate problems’ or ‘parts of the same problem’ are really just two ways of looking at the same thing.

@doofin this particular trait hierarchy is organised the way it is because the Web API is organised this way. This pattern (cake?) is usually not a good idea in Scala codebases. If you want to aggregate methods together into big bags of methods, maybe look at typeclasses instead–they will help keep methods separate and decoupled, and the codebase extensible.