init - data arg - Are we planning to keep supporting a "list of objects"? Note that they don't have to be either data.frame or MAE any more.

[pawelru]

          Are we planning to keep supporting a "list of objects"? Note that they don't have to be either `data.frame` or `MAE` any more.

Originally posted by @chlebowa in #1008 (comment)

[chlebowa]

Note that vignettes have been widely approved that state:

All applications use the teal_data class as a data container. (Including Data in teal Applications)

[vedhav]

I don't see any real issue with us introducing this breaking change in this release.
teal_data can be used interchangeably with list which was not the case before when we had TealData classes. So, the need for list has vanished with this refactor and I don't see an older teal app that would work fine with the TealData -> teal_data refactor but relies on list to work, so it's broken anyway and this change is the easiest to adapt to.

[donyunardi]

I think I interpret the question the wrong way before I start reading the issue related to this. 🤦🏼

Here's what I understand:
This is the current assertion in init(data=):

teal/R/init.R

Lines 122 to 126 in 92301bc

	checkmate::assert(
	.var.name = "data",
	checkmate::check_multi_class(data, c("teal_data", "teal_data_module")),
	checkmate::check_list(data, names = "named")
	)

So this won't work:

But this will work (making it a named list)

We prefer user to use teal_data() for the data argument so having this limitation (not allowing data to accept list of objects) feels okay to me. The hope is that user will be encouraged to learn about the teal_data object (and how to use it). Or, at the very least, follow the right convention by passing a named list object to simplify the conversion to teal_data object.

I guess we can remove/update the skipped test.

[gogonzo]

Historically, data = list(iris = iris) was a nice alternative to

teal_data(
  dataset("iris", iris)
)

and this is why we still keep accepting data as a named list. I think teal::init(data=) should only accept teal_data or teal_data_module, so that:

# accept this
init(data = teal_data(iris = iris), ...)

# instead of
init(data = list(iris = iris), ...)

teal_data call instead of list is still a one call vs one call.

[m7pr]

I would go with possibility to pass only teal_data/teal_data_module so we have less ways of input, hence less to explain (in documentation, vignettes and presentations), in already complex framework. If it's limited, then we can make user spend more time thinking on other aspects of the framework, instead of making him/her figure out what's more accesible for him/hem when passing the data and what's the difference (which is not really important).

[chlebowa]

It seems we are in agreement.
#1051