@aprokopenko sorry for the delay on this, my week has been crazy. Thanks for taking the time to look into this.

1. Can you write some unit tests? Every function and expected outcome is covered in the library so far, and its nice to ensure future changes don't break anything. See https://github.com/StoutLogic/acf-builder/blob/master/tests/FieldBuilderTest.php

2. Can we add dedicated setClass and setId functions and move the specific class and id logic to them? I think people might expect them in the API if setWidth has its own method. Also makes it a little more verbose. The setAttr method can use them in its implementation.

3. What do you think about changing the setAttr method name to setSelector, setAttr is a bit ambiguous. Can this function also parse input with a class and an id like setSelector('#super-id.blue')? I think that would be really handy.

4. Does setting data attributes work in ACF? Does ACF support anything on wrapper other than width class or id? https://www.advancedcustomfields.com/resources/register-fields-via-php/#example only shows the 3, but it could be outdated.

Thanks again for putting the time into this. I really appreciate it.

/1. I can write tests, but would be great if you can merge PR before tests complete. Because we have our own WP tools and I want to set your repo as a dependency. Otherwise I need to set our own fork, then launch a new release after PR is merged.

/4. Yes ACF support anything specified in "wrapper" array. I tested it, when wrote setAttr() method.

2/3. setAttr is named so, because it sets any attribute. setSelector is not the correct name in this case. However if we want to add a feature to write class/id in a one string - it's a good idea for a separate method named setSelector. My opinion that having both setClass/setId and setSelector is too match. So we should choose the class/id methods, or css selector. Please let me know what do you think regarding additional methods, so I can make changes quickly

@aprokopenko I'm not comfortable committing non-tested code to master. You can resubmit or edit the pull request as merging into develop (I just merged the latest from master into it, and develop includes changes from #61 and #63 that aren't on master)

You'd have to include version dev-develop in your project's composer.json and change the min-stability to dev if it isn't already. Though it doesn't really solve the problem of having to change your dependencies later.

2,3,4: Cool if it sets the data fields on the actual field in the admin, then setAttr makes sense. setSelector makes sense as a separate method.

Thanks!

Okay, I will do my best to submit updated code with tests tomorrow then. Would be great if you can review it on weekends or on Monday.

I should be able to on Sunday if not sooner, thank you

Hi Steve,

I added setSelector and tests for all new methods.

This looks great @aprokopenko , I'll release it as 1.8

Thank you so much for your work on this!