Tim spends countless amount of time going through the scripts, read throughs, first recordings, and so on, with Patreons. I've been on many of these read throughs, usually with several engineers in the aerospace industry present, and it's meticulous how Tim makes sure any possible mistake is identified and rectified. Even then, once you upload, there's no editing of a video.
The goal is to bring the subject down to a level where everyday people can still follow. It's not meant to be a college course, so of course there will be some dumbing down.
This assumes that the person fixing the bug is either the same one who filed the bug, or they were motivated to fix the bug after finding the GitHub issue.
In many cases, the fix comes from within Facebook or from a different contributor when we/they run into the issue themselves.
If I recall correctly, many of these warnings come from the default settings provided by the starter Xcode template. As we mostly integrate React Native into existing projects here at Facebook, this is something that we're mostly blind to.
As it happens, someone sent a PR the other day that fixed a bunch of these warnings just in time for the new release candidate we just cut this week. Please give 0.56.0-rc a try. If there's any warnings that still need to be addressed, send a PR or open and issue and ping me. This is something we want to actively clean up :)
There's a long tail of PRs to go through and review, and the ones we review may take a while to get to a point where they are accepted, but saying PRs are never accepted isn't quite accurate: https://github.com/facebook/react-native/pulls?utf8=%E2%9C%9...
I'm one of the open source React Native maintainers here at Facebook, and I'm the one who has set the direction for how issues are treated on our React Native repository.
To anyone whose issue I've closed prematurely, it's OK to feel upset about it. Please do let me know when that happens, as that is the signal I'm looking for. Out of thousands of issues that the bot has closed automatically, only a few dozen end up getting commented on after the fact. Some of these issues we won't reopen because there is no minimal repro (usually because they were opened before we started enforcing the issue template, in which case, please open a new issue!), but in many cases all it needs is for a maintainer to go in and re-open the issue.
If you're reading this and you are one of the people actively participating in the repo, and you'd like to get added to the team that manages issues, please reach out. We have a handful of non-Facebook maintainers with this type of access and we're always looking for more. Shoot an email to my first name @ fb.com.
At this time, we're only automatically closing issues that don't make use of the template. The requirements are actually quite lax: all we ask is for you to run `react-native info` so we can get more information about your setup, and a minimal reproducible example. Questions and requests for help do get sent to Stack Overflow, and this is with the community's best interest in mind as we want to focus on bugs and regressions that affect people's apps. For anything that is not a bug report or a request for help, we have an open-ended discussion template that can be used to file issues that used to get closed automatically in the past.
We used to close stale issues more aggressively in the past, which was needed to get us down from thousands of open issues down to a more manageable state. The bot now only closes issues after four months of inactivity. The bot does give a 30 day warning which should be enough for people to verify if the bug is still present in the latest release, in which case they can leave a comment and the bot won't bug you for another 90 days. This way, we can prune out any issues that got fixed in a release - as others have commented, sometimes the people fixing a bug are not aware that an issue was filed for the bug for various reasons.
But the true purpose of the stale bot is transparency: if there has been no activity in the issue in such a long time, it's not something people should expect to see fixed soon. Typically, issues where someone is able and willing to provide a fix for, or long-running issues describing a problem that does not have an easy fix but the core team wishes to fix at some point, will have some sort of ongoing discussion, in which case we protect the issue from being closed by adding the appropriate label ("Core Team" or "For Discussion").
Finally, I want to point out that the project is open source. If you are waiting for a fix to be merged and need to unblock yourself right now, you can always cut a release off your own fork. Please let us know when you do this, as this helps provide us with some signal about PRs that could be prioritized.
The hosted parse.com service is meant to support hundreds of thousands of apps. It was not really meant to be self-hosted by individual developers serving a couple of applications.
The data export feature was replaced by the database migration tool we launched on January 28 last year. We highly recommend using the database migration tool as this will ensure that all of your data is copied over and synced to your new database prior to switching traffic over. Tons of apps have migrated in the past year using the db migration tool.
The "real" Parse service is built to power hundreds of thousands of apps. The OSS Parse Server you run yourself would only need to power a single app. Two very different use cases.
- "So some stuff blocks afterSave, and some stuff doesn't. Does saving another object from afterSave block a save? What about the nested triggers on that other object? Why isn't that documented anywhere?"
- "I've never seen a reference to this, despite repeated Googling." ... "Instead we Google for "parse set pointer" and this page comes up:"
It sounds like you're leaning a lot on Google searches bringing up two year old questions. There's a massive archive of questions from the last 3 years, around 10,000 on my last count. Going back through every single comment and answer to make sure they're still accurate would be a huge undertaking, and a year ago we stopped using those archived questions.
I highly recommend reading through the entire documentation for the platform you're working on, as well as the API Reference for your SDK. You can find both at https://parse.com/docs. I think now is a good time to point out we're also accepting pull requests against our Docs[1]. We welcome diffs that make the docs clearer for everyone.
It's not too difficult to create a new column that new clients understand, and use beforeSave to propagate updates to this column back to the older columns that earlier clients depend on. I'm not sure I understand the purpose of the "afterRead" hook and how it would help with this use case.
- "If it is the case that afterSave does not block a save, then the documentation is pretty poor around this. My understanding is that afterSave and beforeSave are both required to complete before you'll get a return value from saving an object. If this is not the case, I suggest making this clearer in the docs."
I was wrong earlier. A client will not get a response until an afterSave completes execution. What I should have pointed out is that ongoing http requests to external endpoints will not block the afterSave from returning. As such, you can still use Mailchimp in this case without worrying that a client will be blocked. Of course, you will want to avoid blocking the afterSave on the third party network request (e.g. adding on to the promise chain), which should not be a problem if this is truly a fire-and-forget operation.
- "At the point where you are using Webhooks like this, the advantages of Parse disappear entirely."
I think you're not giving the client-side SDKs enough credit here. Server side business logic is only one part of the equation. With Parse, you also get a data browser, analytics, push notifications, and probably most important of all, a database.
- "It's not cloning a DB that's the problem -- it's programatically updating schema so that I can deploy schema changes to my staging environment and then deploy the matching set of schema changes to prod environment, automatically. This is not possible without a bunch of scripting. And, obviously, there is no easy way to mass-migrate parse objects to a new schema either."
This feedback seems contrary to your earlier ask for a way to script Config variable updates. :) There's the Data Browser for UI based manipulation, there's a Schema API for programmatic manipulation, and there's a dedicated schema migration setting. You can use any of these approaches as needed, and depending on how much scripting you wish to do.
- "This needs to be better documented. Google searches bring up results where people are constructing pointers via JSON and this was indicated to be "the right way to do things""
Adding Parse objects to pointer fields is documented in all of the guides. createWithoutData is an alternate constructor that can be useful when creating pointers explicitly, but it's not the only way of creating a pointer. The link I posted is straight from the API Reference docs.
- "If I want to mass-import data into my system, I'm at the mercy of system timestamps. There are no options to fix this."
These two fields, as well as the object id, can be set to arbitrary values as part of a JSON import. Otherwise, you would not be able to import data exported from another Parse app.
I'm Héctor, a Parse developer advocate for the past 3.5 years. I've probably seen every question related to Parse, spend most days supporting apps with millions of users, and hopefully I can address some of these.
You bring up some valid points, some specific to Parse, others related to backend systems in general.
- "The real problems show up when you've all of a sudden got these old apps out in the field with no way to upgrade them to a newer version of the DB. If you aren't being diligent and making all your Parse DB calls through their cloud functions, you are guaranteed to end up in a situation where your older mobile clients are holding back schema and feature evolution."
Maintaining compatibility with a long tail of old, stale versions of your clients in the field is something all of us need to deal with as app developers. Our examples do place more emphasis on client-originated object updates and queries due to our approach of making it very easy for developers to get started. Some of our more sophisticated developers end up using the approach you've used as an example of moving as much of the operations over to Cloud Code. This is, in fact, one of the reasons we decided to work on our Cloud Code server-side compute environment.
- "beforeSave/afterSave triggers are completely unusable! They are unbelievably limited and each one you add slows your app down by as much time as it takes to run. If you want to do something like add users to Mailchimp, you have now tied the length of time it takes to save a user to the length of time it takes to talk to mailchimp!"
A beforeSave, by definition, will block a save until the operation has finished. Save operations on the client side are performed asynchronously, so this should generally not block your app. An afterSave can be used for things such as sending an email through Mailchimp, which in general you would not block a user operation on, but rather these would be queued up. There are some sensible default timeouts in place to discourage lengthy operations that could lead to a unsatisfying user experience (e.g. creating a new row should not take more than 3 seconds). If you are OK with having the user wait more than 3 seconds, you can use Webhooks to redirect the beforeSave/afterSave/cloud-function computation to a third party server of your choosing. In that case, you would have up to 30 seconds to return a response to the client.
- "There is absolutely no way to test your parse code other than uploading it to a parse app and hitting it. You can hack together some node code that sort-of tests it, but it's nowhere near representative of what happens on the server."
This is a big pain point many of our users have highlighted. Cloud Code is not node, so the best way to test code is by running it on Cloud Code itself. We do not have a good solution for satisfying this need at this time, so I would suggest using node.js on a third party server and taking advantage of Webhooks. This effectively allows you to Bring Your Own Server and provides you with limitless flexibility on what can be done as part of a save hook or cloud function call.
- "You can't manage Parse.Config programatically. There's a web interface and that's that. None of your config can live in your git repo because there's no way to read or write it from the command-line."
I think that everything you can do on Parse should have a REST API equivalent. We've recently launched a Hooks API as well as a Schema API. Perhaps a Config API can be considered. I personally use Config to store credentials that I would not want to be checked in to version control, and I use Parse Objects for anything that changes often enough to require programmatic updates.
- "The schema tools are pretty bad on the website. IIRC they introduced REST APIs to make changes to schema recently, but unless you plan on writing tooling around those, you'll be manually syncing schema between prod/staging at some point in your life and you'll probably also miss a critical column that got added."
You can clone an app and its entire schema from your Settings. This is the best way to ensure there is a 1 to 1 mapping between prod and staging. One thing that is missing from this is cloning data from prod to staging. Bigger apps, with gigabytes of data, could take a very long time to clone. In this case, I would suggest having some sort of seed script that populates your staging database with placeholder data. I understand this does not solve the problem of having an exact copy of your production database, but this is not a simple problem to solve (would you want to keep both apps in sync as the prod app gets updated? would you be willing to wait hours/days for your an initial sync from prod to staging?). With that said, this is something we're aware of and hope to be able to address soon. Stay tuned.
- "Parse has a bunch of weird datatypes that act strangely in their cloud code. Want to make a pointer and store it in a parse field? Construct its internal representation and set it! I wish I was kidding. If you construct a pointer incorrectly, it can actually create a phantom object in another table. Also wish I was kidding about this."
Mucking with JSON to successfully create a valid pointer sounds like an easy way to introduce bugs in your code. You shouldn't need to to do this, use YourClass.createWithoutData(objectId) instead.[1]
- "createdAt and updatedAt are special and Parse won't let you touch them or set them. Heaven forbid you want to actually set these to a meaningful time other than the actual last time the record was written. Nope. So you end up making your own updatedAt columns and just using those."
createdAt and updatedAt are automatic fields set by the underlying mongo database, and you can depend on these being accurate as no user or admin operation can force them to use arbitrary values. You're definitely welcome to create your own Date fields if your use case requires arbitrary values. This shouldn't be too much of a burden, IMHO.
Hopefully this helps! As always, if you have any questions, feel free to join us on our developer community[2].
They only banned me from accepting payments. I can still use them to pay at any establishment that uses Square, which, here in the Bay Area, is a very common sight.
Aside from the refusal to explain why I cannot accept payments, I haven't had any negative interaction with the company. They just seem unable to provide any further information, for either legal or policy reasons.
I went through this almost two years ago, with the key difference being that I was able to sign up with Square and accept payments around four years ago (whenever they launched). I even interviewed there at one point, just like you.
After two months, they closed my account because I was living in Puerto Rico at that time and there are no partner banks in Puerto Rico. Once I moved to San Francisco and linked Square with my new California bank account, I was able to accept payments again.
Then one day I got a notification indicating that my account had been closed, and that the decision is final. I contacted Support, and they reiterated that their decision was final, and could not communicate with me any further.
It is the weirdest interaction I've ever had with a company. I still use them as a payment method and I'm a big fan of the company, but I feel disappointed whenever I log in and they remind me that my merchant account is disabled.
The goal is to bring the subject down to a level where everyday people can still follow. It's not meant to be a college course, so of course there will be some dumbing down.