Automatically disable the save button in release builds #790
Conversation
|
Very cool! 🎉 I suspect we'll want to disable saving or at the very least publishing until we stop using post content as the base, that's what we ideally want people to stop publishing because it really screams "this is a test build", and then the user might be surprised when they publish it on the frontend.
Not worth it, especially since disabling is an interim thing. If need be, and if it's a minuscule amount of work, then we can let people save/publish if they actively open an existing post in the editor, rather than use the stock post content. However even then we should probably work in #707, possibly even decide on #708 first. |
I am assuming that you mean our dummy It's not difficult at all to distinguish between a new or an existing post, but I agree there's value in waiting until the functionality around post statuses is more fleshed out first. |
nylen
force-pushed
the
update/disable-save-in-builds
branch
from
ef1dcc9 to
f28c84f
Compare
mtias
added
[Type] Build Tooling
| return ( | ||
| <Button | ||
| isPrimary | ||
| isLarge | ||
| onClick={ () => saveCallback( post, edits, blocks ) } | ||
| disabled={ ! buttonEnabled } | ||
| disabled={ ! buttonEnabled || process.env.NODE_ENV === 'production' } | ||
| title={ buttonDisabledHint } |
There was a problem hiding this comment.
Reminds me, I have an in-progress tooltip branch which should help surface this a bit better than native browser tooltips.
See #748. cc @jasmussen - if we want to keep the save button disabled (I would think we do for a few more releases...) then this will automate it. This method also has a bit better UX becuse the button is visually disabled rather than appearing to work but doing nothing when clicked.
Should we also add a way for power users to save anyway?