Parse-sdk-js: Opinion - Makes the API more simple and readable like other platform

[lamualfa]

First of all, Thank you very much for this good library.

There really isn't any problem that i get with the current feature and format. But I think, the Parse makes using the API is more complicated for ordinary people when first using it (_opinion_).

Examples

to Perform a Query

Parse

const query = new Parse.Query(Parse.Object.extend("Blog"));
query.equalTo("title", "Hello world");

const data = await query.find();

Supabase (_The Open Source Firebase Alternative_)

const { data, error } = await supabase.from('blog').select().eq('title', 'Hello world')

Firebase

const data = await db.collection("blogs").where("title", "==", "Hello world").get()

to Insert a New Data

Parse

const Blog = Parse.Object.extend("Blog");
const blog = new Blog();

blog.set('title', 'Hello world')
await blog.save()

Supabase

await supabase.from('blog').insert({ title: 'Hello world' })

Firebase

await db.collection('blogs').add({ title: 'Hello world' });

to Perform a Relational Query

Parse

const User = Parse.Object.extend('user')
const Blog = Parse.Object.extend("Blog");

const author = new User();
author.id = 'abcdef'

const blog = new Blog();
blog.equalTo('author', author)
// I think just pass the author.id as a string in .equalTo will also work.
// But i haven't tried it. I just follow the documentation.
// https://docs.parseplatform.org/js/guide/#relational-queries

const result = await blog.find()

Supabase

const { data } = await supabase.from('blog').select().eq('author', 'abcdef')

Firebase

const result = await db.collection("blogs").where("author", "==", "abcdef").get()

---

Do you have any plans to adapt the API ease of these examples? or are you going to stick with complex APIs now?

I don't think you need to delete the old API. You can enter the new method into the main core of the current library so that users have several alternatives for accessing the API.

I apologize. there is not much I can help you with. this is just a suggestion. You can close this issue at any time if it is not useful.

Thank you very much to all contributors

[davimacedo]

I'm not sure if there is something to improve here as, if you prefer, you can also write the following codes using Parse SDK:

// Find
const data = await new Parse.Query('Blog').equalTo('title', 'Hello world').find();

// Save
await new Parse.Object('Blog', { title: 'Hello world' }).save();

// Relational
const data = await new Parse.Query('Blog').equalTo('author', new Parse.User({ id: 'abcdef' })).find();

[dplewis]

@davimacedo I kinda like this idea. I never thought about doing something like this.

const { Query } = require('parse');
const data = await new Query('Blog').equalTo('title', 'Hello world').find();
const data = await Query.from('Blog').equalTo('title', 'Hello world').find();

Query.from could be a static function that returns a Parse.Query instance.

[davimacedo]

It looks a good idea. Maybe we could also allow something like:

const data = await Query.from('Blog', { title: 'Hello World' }).find();

[dplewis]

That could work too, equalTo has been improved to accept an object.

[mtrezza]

A few aspects to evaluate the current Parse JS SDK syntax:

• a) Intuitiveness
• b) Readability
• c) Syntax safety
• d) Extensibility

Analysis:

• a) Intuitiveness
  The common usage of a class initializer is to execute additional tasks as part of the initialization. For example, const q = Parse.Query.fromJson(..) does not merely instantiate a blank Parse Query but parses a JSON with the ability to return a fully configured Parse Query that is ready to be executed.

Conversely, the common usage of an instance initializer using the new keyword indicates a blank instance that is likely to require further configuration or initializes the most basic state of an object. You are unlikely to call new Parse.Query(o).find(); just like you're unlikely to call new Parse.Object(o).save();. Offering Parse.Query.from('Blog') instead of new Parse.Query('Blog') seems to be at best a subjective because cosmetic change, at worst a misleading because unintuitive change, using a class initializer to instantiate a blank query.

Also, from(Parse.Object) is semantically inconsistent with the meaning of fromJson(query), maybe for(Parse.Object) would be semantically more intuitive and distinguishable.

• b) Readability
  It requires more or the same amount of chars, so there doesn't seem to be any improvement in readability:

  const q = new Parse.Query(o);
  const q = Parse.Query.from(o);
  const q = Parse.Query.for(o);
  

  As Davi commented, Parse syntax already offers a level of compactness that is comparable to other platforms mentioned.

• c) Syntax safety
  The more "compact" the syntax becomes, the less safety it provides. The most compact syntax can be achieved with a Parse.Query.fromJson(...) which is somewhat similar to .where("author", "==", "abcdef") both of which provide lower safety for the benefit of flexibility and non-verbosity. The opposite would be a more verbose syntax to support the developer, which is already provided.

• d) Extensibility

  const data = await Query.from('Blog', { title: 'Hello World' }).find();
  

  The generic meaning of from gives the impression that this was a versatile query constructor, while it is really a form of Parse.Query.fromJson(...) that is arbitrarily restricted to the $eq operator. It's not possible to overload this method with additional operators, unless using a syntax that provides the same lack of safety as a raw JSON that is supplied to fromJson(...).

In short: Parse SDK already offers both:

• a raw, unsafe, compact, less readable JSON constructor (programmatic, serializable)
• a typed, chainable, verbose, more readable query factory (manual, intuitive, self-explanatory)

Unless we find an argument for introducing a new constructor method, I think this issue has been closed correctly.