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

modal-ify config #108

Merged
merged 1 commit into from
Oct 5, 2018
Merged

modal-ify config #108

merged 1 commit into from
Oct 5, 2018

Conversation

jlmitch5
Copy link
Collaborator

@jlmitch5 jlmitch5 commented Jun 13, 2018

link #87

config now in modal!

screen shot 2018-06-12 at 11 53 22 pm

@jlmitch5 jlmitch5 requested a review from ngwese June 13, 2018 03:54
@ngwese
Copy link
Member

ngwese commented Jun 16, 2018

sorry for the delay.

i’m thinking it would be best to have ok and cancel buttons like the other modal dialog instead of just a close box - that of course means that changes to settings must be held until confirmation.

...otherwise this looks like a great (haven’t looked at the code yet)

@jlmitch5
Copy link
Collaborator Author

No problem! I can follow the other modals in terms of their closing and saving behavior.

I can also maintain the configs internal state until save.

I also need to check responsiveness I forgot to do that.

Thanks for the feedback!

@anthonybarsotti
Copy link
Contributor

If you guys want I could abstract the modal functionality into a single component that we could inject inner HTML into so that we always have consistent functionality by default with modals.

@jlmitch5
Copy link
Collaborator Author

@anthonybarsotti I believe there's a component that I can inject as the direct child of the modal and pass some props to to keep things consistent right now: https://github.com/monome/maiden/blob/master/app/src/modal-content.js

In usage:

<ModalContent

The config view itself can then be injected as a child of the ModalContent component, I think. I didn't see ModalContent in my initial work on this pr.

Do you think this plan makes sense? If you think there might be some benefits to taking a different approach, I'm happy to hold off on the plan above. Not picky about the implementation!

@jlmitch5
Copy link
Collaborator Author

jlmitch5 commented Jul 2, 2018

@ngwese it now uses the standard save/cancel behavior of other modals, as well as does not persist the state until the save button is clicked.

I used this pattern to be able to have the save function encapsulated within the config activity file, while calling it with the ModalContent standardized save button: kriasoft/react-starter-kit#909

@ngwese
Copy link
Member

ngwese commented Jul 2, 2018

@jlmitch5 thanks for taking a second pass at this. i took a quick pass to resolve the conflicts this has with the current state of master but didn't finish reviewing workspace.js before running out of steam. i'm take a look tomorrow evening. if you get a chance before then to rebase this off master that would be great.

@jlmitch5
Copy link
Collaborator Author

jlmitch5 commented Jul 8, 2018

@ngwese rebased on latest master (and apologies for the delay)

Copy link
Member

@ngwese ngwese left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After a super long delay I've tested this and it looks okay. There are some unused imports that it leaves around but I'll fix those up myself.

@ngwese ngwese merged commit e1d2033 into monome:master Oct 5, 2018
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