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

Feat/albas improvements #644

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

loiddy
Copy link
Contributor

@loiddy loiddy commented Jul 27, 2024

Hi! Not finished yet. Sending it now so you can start looking at it while I continue working on the next bits.

I changed your state approach to show you what I had in mind. I'm not entirely convinced by it. Just leaving it for now so I can move on with the other stuff.

I think it's important to only use state in image-cropper-component.ts to avoid confusion and not to separate the logic in ngOnChanges as it's already a brain bender. We can move it into a function somewhere, but keep it all together. Not in different functions/class methods.

I cringed at the settingsToUpdate input in my state approach. Seems like it should be a method. Which in a way makes me happy cos having only update transform and update cropper as methods was feeling weird to me. This is just food for thought though. I think we should talk more seriously about state once I send you everything and you read through it.

I deleted all the inputs so we can work on a clear-end result. I'll add them back at the end so developers can use the old and new approach like you said.

I've also changed it back to methods updating state values instead of returning the values which are then passed on to state in main. I want to test both approaches at the end to see if there's a difference. I suspect I might be wrong but I still want to test. I understand what you wanted and I like pure functions too. I just want to see if in this case, where ultimately I'd like the lib to be able to do things like scaling when resizing, simply updating the values is better. Same with undefined values and nullish coalescing or ||.

Which brings me to the next part. I saw you were trying to get rid of hammer. How's it going? Hammer seems to be terrible for performance so that would be awesome! Also you can unify a lot of the pointer events logic and put it in utils, further decluttering image-cropper-component.ts.

Any questions, I'm here. Chao chao for now :)

[EDIT]: Forgot, I'll add your tests back too.

Also organised imports, changed to updating properties, no optional chaining, no nullish coalescing or undefined values unless strictly necessary (will test this later).
…as changed.

Parent needs to know that the settings were updated to update view.
…sly checkWithinCropperSizeBounds)

- Changed how cropper size bounds are calculated.
- Changed naming of scaled cropper state values to internal, as we now check all of them –static too– and they follow different rules.
- Added hiding resize squares when static side and changed cursor in non hidden squares.
- Deleted resetCropOnAspectRatio change (explained in the rules section of cropperPosition.utils in changes)
- Change naming of checkWithinCropperSizeBounds to checkSizeAndPosition, and updated it to cover new behaviour explained in rules (see changes, cropperPosition.utils).
- See rules in cropper position and cropper size bounds utils.
- How it moves when resizing when maintain aspect ratio is true
- Can resize when one internal static side is applied
@loiddy
Copy link
Contributor Author

loiddy commented Jul 30, 2024

I forgot to make and send the videos.

I sent changes so cropper can resize when there's one static side (I don't think that needs a video) and changed how it resizes when maintain aspect ratio is true.

Before, it would resize from a corner when resizing from a side.

mov_sideresizingfromcorner-ezgif com-video-to-gif-converter

Now, it resizes from the side:

mov_onesideinmantainaspectratio-ezgif com-video-to-gif-converter

Before, it only resized on x movement when resizing from a corner.

mov_resizingonlyx-ezgif com-video-to-gif-converter

Now, it can resize on x and y movement.

mov_xandyresponse-ezgif com-video-to-gif-converter

But there's still an area where it doesn't respond. This happens in all corners. I gave up on fixing it.

mov_problem-ezgif com-video-to-gif-converter

@Mawi137
Copy link
Owner

Mawi137 commented Aug 27, 2024

Hi there,
The resizing from the side is a nice feature.
I'm not a fan of what you did with the settings though..

@loiddy
Copy link
Contributor Author

loiddy commented Sep 17, 2024

Yeah I'm not a fan either. I like some bits though.

@bboyle
Copy link

bboyle commented Oct 21, 2024

left some comments on the code. I would like to separate this into 2 PRs:

  1. fixes to to the resize transform origin
  2. changes to the settings

I'm keen on the resize changes.
I would rather the settings not change. Those are breaking changes, everyone using this component will need to update their code to use those changes, and I prefer the individual settings — as a component user, they are easier to update.

That's my thoughts

@loiddy
Copy link
Contributor Author

loiddy commented Oct 22, 2024

@bboyle thanks for this :)

So the settings was a mistake and I'm changing it back.

I take it you want the resizing now? If so I'll look into dividing the PR. I think there was a breaking change involved but I can't remember right now. Need to check. For the resizing to work it has to take into account cropperMinWidth, cropperMinHeight, cropperMaxWidth, cropperMaxHeight, cropperStaticWidth, cropperStaticHeight and mantainAspectRatio. I suspect the breaking change was related to updates I did there.

There will be breaking changes with the rest of the changes that I'll be sending in, assuming they're accepted.

@bboyle
Copy link

bboyle commented Oct 22, 2024

No immediate rush. I would like the resize changes, but certainly not an emergency or anything like that.

I consider breaking changes to be anything that means a new version used with the same configuration does not work without the developer making additional changes. If a developer can update to the latest version and it keeps working, or works better (as in the case of bug fixes or new features), that's not a breaking change. If it stops working until I make changes to my code as well, that is a breaking change. I think the changes to settings were breaking, because my existing settings would not have worked. Just how I think (or at least, how I interpret "semantic versioning").

@loiddy
Copy link
Contributor Author

loiddy commented Oct 22, 2024

Okay so I checked. I deleted the resetCropOnAspectRatio input which is a breaking change, specially for the person that added it.

In retrospect I can see how I really put my foot in it by doing such a drastic change to the settings.

With the changes that I'm sending in I'm giving devs more control over how to set and reset the cropper as well as how to position the img. Both of these involve breaking changes – btw I agree with your interpretation of "semantic versioning" – and are also a pretty big behaviour change. I figured better to merge all in one go with a nice explanation so devs know what to change. This way they only have to do this once.

The resizing thing was a by-product of me looking at this code so much. But if I hadn't changed the settings so drastically I can see how I could have not deleted that input and the code could probably be merged now (would need to double check).

However, I'm going to continue without trying to divide the PR as you have said you are not in a rush for the resizing. I will change the settings back too. If you at some point change your mind, do let me know.

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

Successfully merging this pull request may close these issues.

3 participants