use of component properties in stead of methods

[druppy]

Hi …

I am trying to make some real code in Quasar to see how it scales, and at the same time I am using typescript as I hope this will be the start of a larger project (and typescript is really god in case of large projects).

When using typescript, one becomes very aware about what is well defined and what is not. So, in order to call functions on a components, we need to :

• get a ref to the rendered component
• find a definition of this class instance
• cast it to this class
• make the proper call

If we on the other hand used props, we “only” need to bind it to a data value on a view and then the state (that is well defined in both ends) change will be propagate to the component. This way to do it may seem a bit strange, but it makes a lot of sense when building vue models.

So, to be more specific …

The modal component f. ex. has two functions, open() and close() but what it should have is a property called show(or something else) and a emitter that is called do_close, then it is the parent to the modal that maintain its open close state, and the interface can be method free.

This way we follow the recommendation of vue components, as I understand it, and make all things more reactive.

This has nothing to do with the neither Utils or Toast etc. as there are non components interfaces and easy to type define.

[rstoenescu]

@druppy Hi, there’s no mention that you should use props which are actually “actions”. I think a clear separation of methods and props are a better way to do it, with some exceptions. In this case it’s a complicated situation. Modals have animations on open/close and also support the back button which under the covers hooks into the history API (both are asynchronous operations). Simply having a prop show and setting it to true won’t mean the effect is instant due to the asynchronous operations). So you as a developer could bump into trouble if you don’t also listen to ‘@open’ and ‘@close’ emitted events.

Is this something absolutely necessary? The enhancements are not hard to do, just concerning about keeping code as light as possible.

[druppy]

@rstoenescu I know that open/close can be seen as actions or as a state, but calling functions between components makes things a bit messy, specially in a type strong language where components are plain objects and not classes.

If I understand you right, there may be additional logic to be performed on state changes (like hooks into the history logic) but these can be performed in some ‘watch’ login in the component, in the same manner.

I have made code in TS using the current methods, so it is possible but just very verbose, but It does not seem like a clean way to solve this problem, when the primary interface for a component is props.

All this aside, I really like and agree with your focus on ‘light’ and simple code, there are just more than one way to see this

[s.molinari]

I think this discusion is sailing over my head, but is this issue possibly brought up, because of the differences between OOP concepts and functional reactive programming concepts?

Scott

[druppy]

@s.molinari I am not sure that it is the case, it could be related to the concept of what is considered “light” and “natural”, in a component model that has its roots in a more and less pure html API model.

That it is also hard to model in a syntax strong environment, makes it even more worrying, in my perspective.

When we start to use Quesar along with tsx files (I am working on this), I thinks this will be even more clear, as these component properties can be type defined in typescript, but VueJS components ($refs) still need some kind of unsafe casting.

It is more a question of type safety or not, I guess … one that will be constant between Javascript and Typescript in the years to come

[rstoenescu]

@druppy Really don’t have time at the moment to dig in with you, but please keep us informed of your progress. We are interested in making Quasar a great Typescript experience too!

[druppy]

@rstoenescu Ok, thanks … I will dig in a bit more on my own