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

random zap amounts #1263

Merged
merged 16 commits into from
Jul 27, 2024
Merged

random zap amounts #1263

merged 16 commits into from
Jul 27, 2024

Conversation

SatsAllDay
Copy link
Contributor

@SatsAllDay SatsAllDay commented Jul 13, 2024

Description

Closes #1112

Adds an option to enable random zap amounts as a user setting.

Users can opt in to random zapping in their settings. If they enable the setting, they must pick a minimum and maximum random zap in their user settings before being able to save this option.

Random zaps take precedence over a default zap value.

Random zap config is validated to ensure that a min and max is specified, and that the min is less than the max, if the feature is enabled.

Screenshots

Additional Context

N/A

Checklist

Are your changes backwards compatible? Please answer below:
Yes

Did you QA this? Could we deploy this straight to production? Please answer below:
Yes

For frontend changes: Tested on mobile? Please answer below:
I made the desktop window smaller but that's about it.

Did you introduce any new environment variables? If so, call them out explicitly here:
No.

@huumn huumn added difficulty:medium feature new product features that weren't there before and removed feature new product features that weren't there before difficulty:medium labels Jul 13, 2024
api/typeDefs/user.js Outdated Show resolved Hide resolved
@SatsAllDay SatsAllDay force-pushed the 1112-zap-random branch 4 times, most recently from 395c8c1 to e83386a Compare July 14, 2024 01:41
adds an option to enable random zap amounts per stacker

configurable in settings, you can enable this feature and provide
an upper and lower range of your random zap amount
this has been bothering me since we aren't using eslint for linting
@@ -1,4 +1,4 @@
name: Eslint Check
name: Lint Check
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just a nit because we don't actually use eslint.

@@ -101,7 +101,7 @@ export default function ItemAct ({ onClose, item, down, children, abortSignal })
return (
<Form
initial={{
amount: me?.privates?.tipDefault || defaultTips[0],
amount: defaultTipIncludingRandom(me?.privates) || defaultTips[0],
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Honor random zap settings here, too.

@@ -67,11 +67,20 @@ export function DropdownItemUpVote ({ item }) {
)
}

export const nextTip = (meSats, { tipDefault, turboTipping }) => {
export const defaultTipIncludingRandom = ({ tipDefault, tipRandom, tipRandomMin, tipRandomMax }) =>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

A reusable function for determining the next zap value that honors tipRandom and tipDefault

@@ -540,8 +540,31 @@ export const actSchema = object({
act: string().required('required').oneOf(['TIP', 'DONT_LIKE_THIS'])
})

export const settingsSchema = object({
export const settingsSchema = object().shape({
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Had to do this for the cyclic dependency issue noted below

@SatsAllDay SatsAllDay marked this pull request as ready for review July 14, 2024 01:55
@SatsAllDay
Copy link
Contributor Author

I think this is ready for review. Let me know of any feedback!

Copy link
Member

@huumn huumn left a comment

Choose a reason for hiding this comment

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

Sorry for the slow review. The only thing blocking is the sort of redundant boolean. Not a huge deal, but we already have so many columns.

(I'll want to clean up the UI of the zap accordion too, but given that involves zap undos too, I'll do that after merging.)

Comment on lines 33 to 35
tipRandom Boolean @default(false)
tipRandomMin Int?
tipRandomMax Int?
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need the boolean if we can just check for null on min and max. I'd suggest we use a postgres range type too but prisma doesn't support it.

@SatsAllDay
Copy link
Contributor Author

Sorry for the slow review. The only thing blocking is the sort of redundant boolean. Not a huge deal, but we already have so many columns.

(I'll want to clean up the UI of the zap accordion too, but given that involves zap undos too, I'll do that after merging.)

Ok, thank you for the feedback! FWIW, I went with the redundant Boolean so users could explicitly enable/disable the feature which I felt was a more clear pattern, and also so that users could disable the feature without wiping out their configured values.

In any case, I can make the adjustments, hopefully in the next day or two :)

@huumn
Copy link
Member

huumn commented Jul 21, 2024

I think the boolean in the UI does make sense. For the db, I'd just prefer the values. Toggling off an on wouldn't persist old values but I don't suspect that'd happen a lot.

@SatsAllDay
Copy link
Contributor Author

What are your thoughts on keeping tipRandom: Boolean! as part of the UserPrivates in the GraphQL query API, and just having a manual resolver in api/resolvers/user which does the null check on tipRandomMax and tipRandomMin to resolve it, but still removing it from SettingsInput and the db? Basically leave it as a read-only field, computed in the API. I find it nice to have me.privates.tipRandom in the API response to consume in various spots in the UI.

I'm ok either way, but this idea occurred to me as I am working on the above feedback and wanted to get your take.

@huumn
Copy link
Member

huumn commented Jul 22, 2024

Yes that works! That's how zapUndos works I believe.

@SatsAllDay SatsAllDay requested a review from huumn July 24, 2024 16:56
@SatsAllDay
Copy link
Contributor Author

OK, I think we're ready for another review pass!

Copy link
Member

@huumn huumn left a comment

Choose a reason for hiding this comment

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

Still need to QA but no objections otherwise.


let sats = tipDefault || 1
let sats = calculatedDefault
Copy link
Member

Choose a reason for hiding this comment

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

Ohhh cool compatible with turbo zapping!

ekzyis and others added 7 commits July 26, 2024 22:36
* add this day posting job

* put in proper timezone

* make sure we're in central timezone

* schedule thisDay job
* Add WebLN for sending payments

* attach docs for alby

---------

Co-authored-by: Keyan <[email protected]>
Co-authored-by: keyan <[email protected]>
* remove available prop
* 'enabled' checkbox is now always enabled but uses validation
* CheckboxGroup was missing to show error message
@huumn huumn merged commit dc0370b into stackernews:master Jul 27, 2024
6 checks passed
@SatsAllDay SatsAllDay deleted the 1112-zap-random branch July 28, 2024 15:11
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.

Random zap setting
3 participants