Using nested boxes makes it difficult to override parts of those boxes in another box.

[Senjai]

Okay, this is a mouthful

Given

class MainBox
  include LittleBoxes::Box

  box(:things) do
     let(:stuff) { "stuff" }
     let(:otherstuff) { "stuff I dont care about" }
  end
end

If I want to have a test box, that overrides stuff, I have to redefine the box like so.

class TestBox
  include LittleBoxes::Box
  import MainBox
  box(:things) do
    let(:stuff) { "teststuff" }
  end
end

box.things.othersuff is lost when using the test box. I know I can solve this by having box(:things) actually be another class, like box(:things, ThingsBox), then I coudl simple import MainBox, and replace the :things box with say, box(:things, TestThingsBox) but I was wondering if there was a better way of accomplishing this.

Ideally I'd only like to mutate (I know this is a trigger word for most) the existing box imported from MainBox.

Cheers!

[manuelmorales]

Hi Senjai. You are right. When you do box(:things) you are actually overwriting that box with an empty one, hence losing the :otherstuff. Do you think that having a way of extending the box is preferable? Should that be the default behavior of box() or should we use an alternate method like extend_box()?

For simple cases we have been mutating the instance of the box prior to the tests. Example:

# spec/support/test_app_helper.rb

module TestAppHelper
  def main_box
    @main_box ||= MyApp::MainBox.new.tap do |b|
      b.datasets.database = DatabaseMock.new
    end
  end
end

What do you think?

[andrewhood125]

I think implicitly including the entire box by default could end up bad. I am all for an extend_box or some kind of api to allow that, just not by default.

[Senjai]

Ideally, I'd like that when oepning up an existing box you're essentially class evaling your instance of that box since you now own it after importing it. I think it's worth having a dependency tree where you can modify the entire chain to extend it. This can even be a seperate statement to make it explicit that a modification, not a definition is taking place.

The downside is that this introduces mutability into something that as of yet has been unmutable and comes with all the problems that would have. It's a trade off for sure.

@manuelmorales sorry for the hyper delayed response I apologize. Your way would probably work but requires internal knowledge of how boxes are implimented.