everydotorg / donate-button Goto Github PK

Right now, it's loading a stylesheet from onlinewebfonts.com (which we shouldn't use - #7 ), which loads the webfonts themselves from there. It also doesn't have the font-display: swap CSS rule, which prevents the widget from rendering until the web font renders.

We prefer performance over flash of unstyled text (FOUT), so would prefer a combo of the following:

1. inline font stylesheet (not the actual webfont) into the page to avoid needing a separate stylesheet load
2. add font-display: swap to that CSS to make the widget display text before that font loads

<link rel="preload"> tags not necessary since the styles will cause the font to get loaded immediately.

depends on/can be done together with #7

The default style just shows the Every.org logo, which made a nonprofit I talked to feel like it didn't include her branding; we support specifying the nonprofit logo, but only display it in the split pane view.

We should get them to run. Some issues:

• for src/components/EveryMonth/EveryMonth.test.js: Jest encountered an unexpected token - looks like code is not getting downcompiled to node-compatible environment properly
• for docs/every-month/test.js: ReferenceError: window is not defined - looks like code isn't formatted to work serverside either
• Library still uses @testing-library/react despite the app using Preact

Suggestion: along with just making it work I'd also like to switch over to ava as well since its generally a simpler to configure and use tool that does what we need to do.

Bottom green button should say "Donate $42 USD every month" even as I'm typing

Graceful Defaults - allow the widget to be applicable to any non-profit with zero config

• At a minimum, it will be necessary for the non-profit to enter their slug for Every.org

I've created a branch here which has generic defaults which should be applicable to any non-profit. Some key changes are needed for this to be finished:

• There are no images specified in the default config
  • make sure the split-panel version can't be used unless the are provided
  • In future, we could provide generic default images (and descriptions?) #18
• There are no names for the monthly levels and there are 6 levels
  • When the config has levels without names, use this style
    
    instead of this style:
    
  • Let's make this generic and use the same component for monthly and one-time donations. So it would be possible to specify names for the donation levels or leave them unnamed in both monthly and one-time config.

I made a fancy version decider, it needs a design doc

When opening the split widget, it always scrolls up through the images and then suddenly changes to a different one.

Recording: https://app.usebubbles.com/t41LsSgpJTcmjr5Q5AwdCw/comments-on-localhost/

Suggestion: always have a "currently selected item", and display the image based on that. disable the scroll animation on widget open.

Should see if there's a lightweight way for us to get error reporting going on the donate button, for example through Sentry as we do with all our other packages.

Not sure how they embedded it, but they ended up copying the code from our example to do it instead. Figure out why it screwed up.

The following makes sense to me:

• When we push to some branch, a Github Action kicks of a deploy
  • This should be after CI completes successfully; see #22
• Deploy from a separate branch altogether, not a docs folder
• Versions are deployed to a folder called /donate-button-v2 where 2 is the major version as in package.json
• Github action looks at the package.json version.
  • If minor or patch change from a previously deployed version, overwrites the folder
  • If major change, creates a new version
• old major versions are not deleted, they remain hosted so that clients on old versions dont break
  • though at some point we will need to deprecate old version and then forcefully move clients to newer ones, since we won't be supporting everything forever.

Originally posted by @osdiab in #31 (comment)

they dont run now (and there's none of them)

When people choose to enter an amount, we should ensure it's a whole positive number >= 10 and less than 1 000 000

Example error message from every.org:

@jake-nz are those transforms still relevant when this project uses preact?

related to #23

Right now, we've disabled Cloudflare caching altogether for the assets.every.org domain, which is connected directly to the github pages instance for this repo.

If we want to bring that back, we can - but we need some strategy for busting the cache when new versions are deployed.

At the current moment, by default 200's get cached on Cloudflare servers for 2 hours by Cloudflare, so new versions may not show up for a while. It also seems that Github pages is applying a 10 minute browser cache header to its responses, too.

So a few options:

• We could bust the Cloudflare cache by issuing an HTTP request in a github action when the github page gets deployed.
• We could apply a timestamp query parameter when requiring the JS file, to cause the browser to request new content
• We could switch to Vercel and let Vercel manage smart caching settings itself

need to discuss the future of how we will be deploying this app as we move forward before deciding on this though, so low priority

WHEN I go to ffungi website
THEN the layout should be as the following:

Desktop

Note that everything should be centered now.

Mobile

Note: please make sure we delete the label "international NGO" in mobile

AND the "donate" button on the header should open the widget in the one-time donation flow
AND the "donate monthy" should open the widget in the monthly flow

Spanish traslations for the buttons:
Donate -> Donar
Donate Monthly -> Donar mensualmente

It uses antiquated dependencies that Dependabot is complaining about, which is how I found out that it is deprecated on the node-sass repo.

We have lots of free credits with https://www.lambdatest.com/ can we make it so that https://every-month.vercel.app/ can accept query params to control which version pops up? And maybe host it at https://assets.every.org/ same as the bundle? Then we can periodically load both versions on a bunch of different browsers and make sure it looks good.

1. The default options feels like there is one missing - either let's add a fourth option $500 or make each option full-width same as when there are names for the different levels of support.
2. Scrolling feels quite strange, kinda like i'm still on the other page. There should be no scrollbar at all since everything can fit on my screen.

Suggestion: add prettier and ESLint and enforce an out-of-box, autofixable coding style; can reuse the same ESLint rules we set for the rest of Every.org code (or use xo, but ESLint is fine IMO)

We are going to have 2 different buttons, one should open the one-time widget and the other the monthly widget.

We need to add a prop to choose which widget open by default.

Since this is such a small component it would be nice if we didn't have to include the entire react-dom bundle just to render this, which takes ~40kb compressed. assuming we're sticking with react for sure and not just implementing it in raw JS, this seems like a good candidate for switching to preact/preact-cli instead due to the component's limited scope.

not high pri given that this isn't widely distributed and nobody's complaining, but could be a nice technical touch.

Would be nice if every.org got backlinks from sites that use this button widget.

We can make the button instead be an a element whose href is the donate URL, but whose onClick handler calls e.preventDefault() to avoid navigating to every.org before popping the widget. What do you think?

After doing #49 , let's decide where it should go. Right now no way for user to set the version they're using, it's totally in our control - we should potentially expose that

There's a lot of magic numbers, hard to work with sizing; we can tighten up the styling

Should make sure that bundle.js is always available, as it went down with a recent merge to main today. We can use pingdom or something

it's brittle and makes it hard to understand how the build system works

Ideally, the entire widget should be displayed in the viewport in desktop.

Examples of how it's displaying currently:

The top of the widget is obscured

There shouldn't be a scrollbar. Viewport: 1536 × 722 px

Would be worth checking other screen size variations too, to see how well it displays across the board.

After clicking donate you just see a loading-spinner forever. We should make it link to a real flow, or maybe it would make sense to have a testing mode that links into staging.every.org?

Not sure what that website is, but we have the font assets being served via CDN already directly from our site, so we should prefer using those.

The code seems to expect that you either don't customize any of the text, or you customize all of it - which makes it harder to provide a simple configuration. For instance, if you change the header text, but then don't provide levels because you want to just use the default one, it errors.

We can do just as well by using a zero-runtime css-in-js solution like Compiled CSS in JS or Linaria for a robust but lightweight CSS toolkit

probably compiled is better after looking at everything since linaria forces you to ship a CSS file whereas Compiled currently does it inline (and can support extraction if we want it)

Make sure it works well, make clear docs on what to do on README

Probably release a preact library, and then a react wrapper (with react as a peer dependency). Document it

A lot of nonprofits use Wix, one wants to implement it now - make it easy to deploy to Wix and document it well, for now README is fine

We probably need to do some version bumps. Also will check if dependabot is enabled

That was not intuitive! related to #60

Throwing this out since other Every.org code is all in TypeScript and a switch to it would be pretty simple for me to implement. Is P22 team open to that @jake-nz ?

Causes #51 , changed due to #31 , unclear due to #49 not being done, potentially will change due to #50 . The current code assumes a single bundle JS file, pretty sure that's outdated.

Would be nice to generate the options/examples automatically from source with something like JSDoc.

since I don't have access to the Vercel project, it would be useful to have access to it so that we can inspect what it's showing - can you give us access @jake-nz ?

I assume it's using an old version of the codebase, since it seems to be loading a script called webComponent.js, which only shows up in the every-month bundle, which I believe is a legacy version of this component. We should make it clearer how the Vercel demo is being served and deployed - it seems to be using index.html, but that file has no script tags in it (i think Preact does something magical?), so it's unclear to me what exactly is being rendered. is Vercel hooked up to Git for deploys?

I think it'll be common as we roll this out for nonprofits to not always provide images - perhaps we can have some nice abstract defaults or just not show the image pane altogether if no images provided.

Another situation is if the nonprofit provides images for some but not all levels.

Right now we show a full config blob, would be nice to show the shortest path to working on the docs as well.

When you hover over the button with a mouse on desktop, it doesn't show a pointer cursor; I think we should apply that style by default.

Recording: https://app.usebubbles.com/gYKzBvwgD3afTaBXYKaKju/comments-on-ffungi-org/

Suggestion: Add cursor: pointer to the default styles for the button

Every time you select "custom image" without anything being selected yet, it does a jarring image transition.

Recording:

https://app.usebubbles.com/6vKCRaUgP2nVcEReQaDG9k/comments-on-localhost/

Related issues: #9

Suggestion: don't control the image based on what's currently focused; if you select the "custom amount" and then blur the input without explicitly selecting something else, it should still internally consider the "current" selection the "custom amount" input, and therefore not change the image displayed.

It seems that the first time the component is up, it shows an incorrect bg color on the split pane, and then suddenly changes to the correct one. Additionally, the other levels all switch to the same bg color when you click an option, causing it to look like the you're not going from one color to another.

• if changes are made to cloudflare-worker and pushed to a production branch
• then a github action gets spun up after CI tests complete
• that runs wrangler publish to publish our cloudflare worker to prod

Originally posted by @osdiab in #31 (comment)

Thinking that Github Actions would be sufficient.

Are there extra steps necessary to run this locally? Getting this error output, seems to be from craco monkeypatching. might want to make that script more robust.

(node:17543) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'match' of undefined
    at configure (/Users/omardiab/code/every.org/donate-button/craco.config.js:18:28)
    at giveTotalControl (/Users/omardiab/code/every.org/donate-button/node_modules/@craco/craco/lib/features/webpack/merge-webpack-config.js:28:25)
    at mergeWebpackConfig (/Users/omardiab/code/every.org/donate-button/node_modules/@craco/craco/lib/features/webpack/merge-webpack-config.js:63:38)
    at overrideWebpackDev (/Users/omardiab/code/every.org/donate-button/node_modules/@craco/craco/lib/features/webpack/override.js:11:36)
    at /Users/omardiab/code/every.org/donate-button/node_modules/@craco/craco/scripts/start.js:24:5
(Use `node --trace-warnings ...` to show where the warning was created)
(node:17543) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:17543) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
✨  Done in 6.28s.

Make sure it works well and probably place the instructions in wiki, linked from README; can use wix instructions as an example

The options format as is is pretty brittle, with a lot of stuff failing if you don't specify them just right. For example, levels need to be duplicated in multiple places, changing behavior in the i18n blob, and specifying incorrectly can lead to confusing behavior and crashing, when one would assume an i18n blob would be totally optional and only impact display.

With a major version bump let's make a cleaner, less failure-prone options format that better allows for partial inclusion of options and avoid contradictory settings. Using TypeScript will also help us make sure that we don't blow things up unexpectedly. #11

This project uses preact but the DonateButton package still refers to react. Is this intentional? @jake-nz