Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforcement CaseIterable needs to be optional #48

Closed
404wasfound opened this issue Nov 7, 2022 · 6 comments
Closed

Enforcement CaseIterable needs to be optional #48

404wasfound opened this issue Nov 7, 2022 · 6 comments

Comments

@404wasfound
Copy link

404wasfound commented Nov 7, 2022

By making all the enums CaseIterable you essentially breaking all the projects which have their resources separated in different folders, cause now all the resources of the same type are under one huge enum, instead of the nested ones. Have to fork the tool to fix it now.

@404wasfound 404wasfound changed the title Enforcement CaseIterable needs to be an optional Enforcement CaseIterable needs to be optional Nov 7, 2022
@mickeyl
Copy link
Collaborator

mickeyl commented Nov 7, 2022

I'm not sure I understand that. The nesting is independent from the attribute CaseIterable. Can you show me a diff for you between an older version and a newer one, so I can see how it breaks?

@404wasfound
Copy link
Author

404wasfound commented Nov 7, 2022

hey there @mickeyl! thanx for the response! tbh do not even know how to show the entire thing, will share a screenshot with some parts of the diff so you have a better idea

So we used to have all the resources separated in folders, on that screenshot you see the deleted parts of previously generated enum for images
Screenshot 2022-11-07 at 16 50 56

And now all the resources are just under one resource specific enum (I, C etc.)
Screenshot 2022-11-07 at 16 52 55

@404wasfound
Copy link
Author

So if we take for example the very first case from the screenshot with deleted parts, ic_standard_business, in the code we referenced it as I.Address.ic_standard_business, but now it is just I.standard_business. Naturally that happened to all the resources.

Imho previous approach was better especially for the projects with tons of different resources, was way easier to navigate and find resources case enums reflected the folder structure in resources.

@mickeyl
Copy link
Collaborator

mickeyl commented Nov 7, 2022

@404wasfound Ah, I think this is due to the new corrected folder handling. Please have a look at the README again. If you want Shark to turn a folder into a namespace, you need to check the [x] Provides Namespace below

for every folder you're using. Previously, Shark did create a namespace for every folder, no matter whether the checkbox was ticked or not. The new behavior is correct, although it requires you to adjust your projects. Sorry for the inconvenience.

Please check after checking the folder checkboxes whether this returns your Shark file to the previous state.

@404wasfound
Copy link
Author

provided you have configured the respective Xcode setting Provides Namespace

ooohhhh now I see ... so the previous folders handling was not correct? will try it now, thank you for the info and sorry for bothering!

@404wasfound
Copy link
Author

@mickeyl worked, thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants