Add Parse.Object.getClass(className)

[Aetherall]

So we can retrieve Classes from ClassNames

I can do a PR if needed

[flovilmart]

What would be the use case? Getting the classes instead of importing the module that defines your class? Not against on the paper, but i’d recommend using the node require / import instead.

[Aetherall]

I am creating a Collection class extending the Parse.Object class, where I use decorators on instance methods/properties as well as on static methods/properties to add "configuration" and functionalities to my objects. As it is abstracted from the Parse.Object itself, It makes no sense to import another collection in here. ( Furthermore that the Collection used in the method depends of the actual extend done to Collection )

@register
class Post extends Collection{

    set title(title){
        if(title.length > 50) throw new Error('The title is too long')
    } 

    @label('Title of the post')
    @perm.set(admin, owner('auhtor'))
    static title = String

    @disconnect(owner('author'))
    @connect(admin)
    @relation.one
    static author = 'User'
}

[flovilmart]

Are you willing to make a PR for it?

[flovilmart]

I also really like this decorator based SDK! Any chance you have it on GitHub?

[Aetherall]

Yes, In fact, I am currently rebuilding Parse from scratch ^^
I am making good progress so far

[flovilmart]

rebuilding Parse from scratch

You mean the SDK or the full server+ sdk’s?

I’m curious why you’d need to rewrite it all.

[Aetherall]

Full server + SDK

I do not feel comfortable about how the server and the client work together

The whole concept is great, but the way its designed seem not ideal for me

My goal is to have something like a client execution for each request on the server, but in a way that allows node optimizations. ( no new class instances, just a context shift )

Also, the Parse.Promise thing was driving me crazy aha ^^

With field level validation, the need for ACL is reduced, so I got read of it too
( permissions are in fact functions you define in the form =>
canCreatePost(user, post) or canConnectPostToComment(user, post, comment) )
(it's not verbose like this, it was just an example )

Also, I got rid of the User part, so I can use any user system I want, just bind the user to the request via a middleware ( Accounts-js does the job well )

The framework will not be optimized for large projects at the beginning ( in term of relations between collections ) but if people are interested I can improve that

To conclude, my goal is to extract the data part of Parse, and make it something easy to use, and more relationship oriented than Apollo ( and react compatible as well )

[parse-github-assistant]

The label type:feature cannot be used in combination with type:improvement.