-
Notifications
You must be signed in to change notification settings - Fork 18
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
Refactor and reactive-config
prop feature
#190
Refactor and reactive-config
prop feature
#190
Conversation
…ect rather than mutating the args
…oes not work for functions)
- Refactored a lot of code to combine redudunant operations and move logic away from Vue component. Was able to remove lots of code from API methods by consolidating it into other methods. - Cleaned up the process for getting a promotion (now just sends it back via a callback function) and improved the PromotionDialog component. - Added a set config method to the API with the intention of making it possible to have a reactive config that watches the config prop for changes and updates the board config as neccessary.
Turned off 'vue/require-explicit-emits' rule as this seems to be a Javascript rule that does not work well to Typescript. Other linter rules already flag undeclared emits (so this rule is redundant) and it does not understand the Typescript generic type arguement way of specifying emit type (so it is unhelpful).
It can be turned on as a prop and defaults to false to preserve backwards compatibility as new behaviour may be surprising if implementation doesn't expect it
The previous test was perfectly valid formatting, but the scanner doesn't seem to understand it. Perhaps this will be better?
fixed test
Thanks for your pr. This looks very good. I will take a closer look at it tomorrow. Pull request are very welcome, you can definitely keep developing here if you want to. |
I discovered that Chessgrounds only allows the color whose turn it is to move when `movable.color` is set to 'both', so theres actually no need to switch it back and forth between 'white' and 'black' manually every turn. This kind of makes the `player-color` prop a bit pointless, as it turns out to just be a proxy for a config value. Instead of removing it I've kept it for backwards compatibility and simply merge its value into the config during `setConfig`.
Actually there is a minor difference in functionality between the two approaches. When using 'both' you can't move the non-turn players pieces, but you can pick them up. Whereas the previous functionality was the pieces could not even be picked up. Reverting commit for consistency.
Forgot to remove this while reverting previous commit, sorry for the commit spam!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! Thank you.
I will include this pr in v1.2 release. I will release an alpha version soon, for testing. But we can try also include your other planned changes in it. |
I've created a pre-release with your changes. npm i [email protected] |
Hi, thanks for including my changes. Sorry I've not made another PR with any of the planned changes yet, I was implementing the threefold repetition event and found a bug in chess.js, so I fixed it and made a PR and that kind of lead me down a chess.js rabbit hole making more changes. Once I've finished with some chess.js changes I'll be back to work on the above planned changes. |
Made the following changes:
I understand this is quite a big PR and I plan on continuing development so feel free to let me know if you'd rather I just fork the repo instead! 👍
Also very new to typescript and frontend stuff in general, so any and all feedback very much welcomed :)
Planned changes:
Premove supportEdit: added!