How to handle large, multi-directory changes

[jackiedunne]

We want to run an experiment with many changes across multiple directories - components, containers, state etc. Is there any lightweight way to us the toggle point library for all these changes that doesn't involve essentially creating a copy of these directories and bloating the build?

[TomStrepsil]

Hey @jackiedunne - great to hear from you!

The library is based on the idea of creating duplicate (or extension) versions of all the files you want to vary in an experiment / toggled variation, wherever they are in the codebase. So, you should only have to create copies of the exact files that need to change for the variation, and can opt to extend the base files (where appropriate) to avoid DRY if wanted (this comes with a latent cost whereby the extension must be "normalised" into a final form at the end of the experiment, rather than just copying the varied file over the base file - however, you will probably find CoPilot is adept at doing this for you!)

On the question of bloat - I would suggest that nearly identical files will probably compress very well, so may not materially affect bundle sizes when compressed, but the sentiment that variations shouldn't affect the "baseline" of the application is what underpins issue 16, resolved by (unfortunately, what ended up being very large) pull request 38.

[TomStrepsil]

The screenshot shows css files - you may need to create a bespoke toggle point configuration (rather than the default, that only caters for javascript/typescript files) to branch these - and there is a caveat in that the library doesn't support named exports, which means de-structuring from css-modules is fiddly (see issue 4) - but it is possible, see the "event" fixture from the serve example which varies the css for a component.

Happy to sit on a call, if/when appropriate, to understand the requirement better!

[TomStrepsil]

p.s. It's possible to set up multiple join point configurations for each "type" of file needing toggling (e.g. react components, react hooks, redux modules, css files) - connected to a specific "toggle point" (which understands the nuances of varying that type of code). They can all work in unison for a particular toggle / experiment.

Also, #40 may help deliver a more nuanced join point configuration, targeting specific directories (or files if needing to be even more explicit) to join a particular point cut, if a single glob is proving difficult to configure.

[TomStrepsil]

p.s. also worth noting that if the number of folders you'd have to create is the main concern, a pertinent conclusion of the medium articles that introduce this project may be relevant:

There is no one-size-fits-all for toggling, and this setup should no doubt only form part of a mature toggled estate. It lends itself well to Multivariate testing, where separate parts of a codebase are modified in a multitude of ways.

However, for toggles with certain lifecycles, or with drastic enough deviation in an A/B experiment, it may be prudent to use entirely separate builds running in production, based on separate source control branches, with a toggle router directing traffic. As long as their is no combinatoric overload of potential toggle states to support, it may be a more convenient approach for some workflows.

However, it is perfectly possible to contrive a file system convention, using the toggle point webpack package, that allows a single "variation folder" to hold all the varied code, essentially acting as a "parallel filesystem" (with select modules replacing the base/control, if they exist). It would simply need an appropriate joinPointResolver and toggleHandler to map from a nested module in one folder, to a parallel.

Happy to help design this with you - alternatively, you might find agentic AI, given free reign to read the documentation in the repo, does a reasonable job.

[TomStrepsil]

p.s. could consider cross-posting this as a "q&a" discussion

[jackiedunne]

Hey Tom, lovely to hear from you too. Thanks so much for your response :). I have to admit though, I'm a little at a loss at hwo to handle toggling all these changes. I've tried a few times to do them individually and it just turns into a mess.

It's possible to set up multiple join point configurations for each "type" of file needing toggling (e.g. react components, react hooks, redux modules, css files) - connected to a specific "toggle point" (which understands the nuances of varying that type of code).

Would it be possible to get some guidance on how to implement this?

[TomStrepsil]

Hey Tom, lovely to hear from you too. Thanks so much for your response :). I have to admit though, I'm a little at a loss at hwo to handle toggling all these changes. I've tried a few times to do them individually and it just turns into a mess.

Understood; happy to get an example up ASAP if that would be useful. I appreciate it can be fiddly (as conceded here) to create bespoke toggle setups.

It's possible to set up multiple join point configurations for each "type" of file needing toggling (e.g. react components, react hooks, redux modules, css files) - connected to a specific "toggle point" (which understands the nuances of varying that type of code).

Would it be possible to get some guidance on how to implement this?

Sure - I think the PR I left before leaving ASOS for PLP had this setup (different toggle points for react vs redux, at least) but looking at the site I'm not sure that's been merged. It didn't include toggling CSS (but, on the whole, wouldn't recommend varying this directly if there's an option of varying a react component that uses a different CSS file instead, since it means you lose the ability to de-structure class names - as per example here) - perhaps could find a time to go through that PR, and see if it can be extended for your use-case.

[TomStrepsil]

p.s. I think, until the Load Strategies PR is merged, the ability to use a parallel nested filesystem is restricted - see #54 - I will carve a subset out of the load strategies PR (for easier consumption) that just caters for this, ASAP - along with an example that uses a parallel multi-folder toggled filesystem.

UPDATE: the enabler is here, which implements parts of the load strategies PR (with hard-coded static load strategy, mirroring the current version). This should allow any connection between base and variant file; I'll knock up an example as a separate PR to demonstrate.

[jackiedunne]

@TomStrepsil I've approved the PR, do you want someone else to look at it?

[TomStrepsil]

I'm happy if you are! I don't have the option to merge, but let me know if you do - I can then fix up the example I was preparing, to utilise this update.

I'm conscious that ASOS PLP is probably still using the internal version of toggle point, unless the PR I left last year has since gone in (as alluded above). That will probably be a pre-requisite of moving to this upgraded version, FYI.

[jackiedunne]

Yup I can merge, the PLP PR hasn't gone in unfortunately. The only reason being that no one was confident enough to understand what it was doing to fix the merge conflicts and test it thoroughly.

[TomStrepsil]

the PLP PR hasn't gone in unfortunately. The only reason being that no one was confident enough to understand what it was doing to fix the merge conflicts and test it thoroughly.

Understandable, it was dropped rather late before my departure, and timing was poor with re-structure in flight. Happy to pair on fixing up and code conflicts, but perhaps wait on the example I can provide, so you can get a feel of what it might look like in an end state.

My evenings are somewhat busy this week sadly, but if I can steal some time when travelling, I'll hopefully get the example into a good state - and then perhaps can find some free time to pair remotely, if possible, on fixing up the PLP PR, if that'd be desired, from next week onwards.

[TomStrepsil]

Hi @jackiedunne - apologies for delay.

I have a draft up at TomStrepsil#3 that demonstrates a parallel filesystem convention, varying React, css, constants and Redux code - but it's somewhat reliant on both #55 and #43 being merged first. Happy to talk it through, but probably best to pull it down and see it in action - may need to cross-merge code from #43 into it to get it working, since it's currently pointing at #55.

N.B. It's based on "modern redux" (redux toolkit) - not sure if that's in use yet at ASOS, but I thought it prudent to make an example based on that.