locaizeAndFormatDate formats the first hour of the day as 24:00 instead of 00:00 for en-US

To Reproduce Steps to reproduce the behavior:

1. Run yarn test
2. There are three failing tests:

FAIL  src/util/dates.test.js
  ● date utils › getMonthStartInTimeZone() for 2019-11-23 › should return correct start of the month

    expect(received).toEqual(expected) // deep equality

    Expected: "11/1/2019, 00:00"
    Received: "11/1/2019, 24:00"

      313 |           getMonthStartInTimeZone(date, 'Australia/Eucla')
      314 |         )
    > 315 |       ).toEqual('11/1/2019, 00:00');
          |         ^
      316 |       expect(
      317 |         localizeAndFormatDate(
      318 |           intl,

      at Object.<anonymous> (src/util/dates.test.js:315:9)

  ● date utils › nextMonthFn() for 2019-11-23 › should return correct start of the next month

    expect(received).toEqual(expected) // deep equality

    Expected: "12/1/2019, 00:00"
    Received: "12/1/2019, 24:00"

      337 |       expect(
      338 |         localizeAndFormatDate(intl, 'Australia/Eucla', nextMonthFn(date, 'Australia/Eucla'))
    > 339 |       ).toEqual('12/1/2019, 00:00');
          |         ^
      340 |       expect(
      341 |         localizeAndFormatDate(intl, 'Europe/Helsinki', nextMonthFn(date, 'Europe/Helsinki'))
      342 |       ).toEqual('12/1/2019, 00:00');

      at Object.<anonymous> (src/util/dates.test.js:339:9)

  ● date utils › prevMonthFn() for 2019-11-23 › should return correct start of the next month

    expect(received).toEqual(expected) // deep equality

    Expected: "10/1/2019, 00:00"
    Received: "10/1/2019, 24:00"

      353 |       expect(
      354 |         localizeAndFormatDate(intl, 'Australia/Eucla', prevMonthFn(date, 'Australia/Eucla'))
    > 355 |       ).toEqual('10/1/2019, 00:00');
          |         ^
      356 |       expect(
      357 |         localizeAndFormatDate(intl, 'Europe/Helsinki', prevMonthFn(date, 'Europe/Helsinki'))
      358 |       ).toEqual('10/1/2019, 00:00');

Screenshots

Expected behavior

locaizeAndFormatDate should format the first hour of the day as 00:00 and tests should not fail.

Additional context

The issue is due to insufficient configuration of intl.formatTime function. It does not accept hourCycle: 'h11' that is required for the expected format.

More on that here: formatjs/formatjs#1577

From the documentation, the only production environment supported for deployment is Heroku. Our organization only runs its applications and data infrastructure in AWS and would prefer to host there. Can the team outline hosting instructions for AWS environments? There is no preference to what AWS services would be used to host the application.

There's been security issue opened related to immer package (fixed in 8.0.1)

That dependency comes from Create React App and it's used for development time:
facebook/create-react-app#10411

Describe the bug

When entering payout details for Japanese bank accounts the submit button remains disabled even when all the details are correct.

To Reproduce

1. In a testing account (with a test Stripe key), go to Payout Details page.
2. Enter the following test details:
   Branch name: Akasaka
   Branch code: 000
   Bank name: Sumitomo Mitsui Banking Corporation
   Bank code: 1100
   Bank account owner name: John Doe
   Bank account number: 0001234

Expected behavior

As those are valid details in a Stripe test environment, the submit button should become enabled.

But even though Stripe successfully returns a token, the submit button remains disabled.

Additional context and possible solution

The problem seems to stem from the fact that FTW is sending unrecognized parameters to Stripe as can be seen here:

When Stripe returns those values with the token it does not remove whitespaces from them.
FTW, on the other hand, expects those values to be "cleaned" (spaces removed) as can be seen here:

Since the result that returns from Stripe is different than expected, valuesAreUnchanged is greater than 0 (see line 156 in the link above) and the submit button remains disabled.

I was able to get around the problem by not cleaning up those two values:

const changedValues = inputsNeeded.filter(
  inputType => {
    // Stripe does not "clean up" the `bankName` and `accountOwnerName` strings
    const expected = ["bankName", "accountOwnerName"].includes(inputType) ? this.state[inputType].value : cleanedString(this.state[inputType].value);
    return values[inputType] !== expected;
  }
);

But that seems like a hack and I am not 100% confident how this will affect other countries, and whether there are other such unrecognized parameters in other countries besides these two.

When adding new photos to an existing listing the added photos are duplicated after form submission.

To Reproduce Steps to reproduce the behavior:

1. Go to edit existing listing
2. Upload new photo
3. Click 'Save photos'
4. See newly added photos duplicated

Additional context The problem was introduced with 0291482 and causes the imageOrder field doesn't get cleared after submission.

**In ftw-hourly template when you go to the listing page, you click on the calendar and change the month in the calendar and select a date from that changed month, you won't get to see any of the timeslots. I debugged the issue and found out that the currentMonth was resetting to the original current month not to the changed one.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Listing Page'
2. Click on 'Date Picker', where you get to select the booking date,
3. Change the month.
4. Select a date from the changed month.
5. You will see that you won't get to see any timeslots in that particular day, even if there were.
6. This is because the currentMonth in the state is resetting to original current month not to the changed one.
7. This is all happening because of new onClose function passed to the date component.

Here i clicked on the calendar and changed the month to december

Here i selected the date from the month december and i didn't got any slots to select from.
As you can clearly see what the problem is, the currentmonth is resetting to old current month.

This is what IMO causes the issue.

Also all calendar days are disabled because of wrong month in the state.

Expected behavior
When you change the month, the timeslots of that changed month should have appeared so that the user can select from those as per his need.

Solution
I have also found a solution to the problem. If you allow me I may present my solution.

Currently I am using MacOS, I have faced the same issue when i was using a linux based machine.

Calendar entries are lost after the calendar inside FieldDateAndTimeInput is closed and it's unavailable to select date/time.

To Reproduce Steps to reproduce the behavior:

1. Go to the listing page
2. Click on calendar input click next month arrow and select date.
3. Calendar is closed and no time entries are available
4. Open calendar again and no dates are available

Expected behavior
Calendar works correctly

Screenshots If applicable, add screenshots to help explain your problem.

Additional context
Only happens when changing the month. The currentMonth is reset before it's actually used inside onBookingStartDateChanged callback.

When removed onClose prop introduced in #158 everything started working correctly.

slack link on main readme says it is not active anymore

There seems to be an issue with Jose, which prevents me from starting up the backend.

Steps to reproduce the behavior:

1. Clone this repository and navigate to the directory cloned into;
2. Add keys etc in .env file;
3. Run yarn install;
4. Run yarn run dev-backend;
5. See error.

• OS: Windows 10, WSL Ubuntu 20.04 LTS
• Yarn version 1.22.5

Describe the bug

It is encoded incorrectly in the API request like so: pub_category=has_any%3Acar

To Reproduce Steps to reproduce the behavior:

add config: {searchMode: 'has_any'} to a SelectMultipleFilter in marketplace-custom-config

if you use the filter through the UI you will see that the first selected option appears to be ignored (i.e. results that should match this option will not be returned by the API). That's because of the encoding described above.

This repo (along with ftw-daily, and ftw-product) are excellent starting points for sharetribe apps.

However, I believe that it is critical to add TypeScript support to it, as without it it is much harder to navigate the codebase.

Would you consider investing time into making it strong typed?