plot() / print() methods about bayestestr HOT 4 CLOSED

Thanks to your code snippet I am currently making some progress on table printing (currently in report), so we can then see if/how it is enhancable and transferable to bayestestR :)

from bayestestr.

However, I am not sure about plot methods... I see plots as end-level stuff, and I had a bad experience in psycho that included some premade plots (I found it difficult to maintain / test) - but please do try changing my mind ☺️

On the other hand, though, I agree that (pre-backed) plots are very much appreciated by (beginning) users. So that's something we have to consider either way. Due to the need for deps (ggplot) for cool plots, and the amount of work needed on its own for it to be great, I think it would be safer to put it in a second high-level package devoted to providing plot functions and methods (especially for our objects, such as bayestestR's results).

In my workflow I strongly rely on own-made functions to transform models/results into the "plottable" data, which I then pipe into ggplot's awesomeness. Thus, it could be useful, down the line, if we add an easyplots package, to have two lines of functions: the first "data_for_plot"/"get_plotdata" would transform an object into plottable data, and "plot" would return a default plot (of course, directly calling the latter would internally call the former).

In the end, new users could just do equivalence_test(model) %>% easyplot(), whereas more advanced users that want to use ggplot manually would do equivalence_test(model) %>% plot_data() %>% ggplot(...

from bayestestr.

That sounds good! I think we should go into this direction. We just need to take care of having not too many fragmented packages - I think I have mentioned this already elsewhere - it doesn't make much sense for our goal to reduce dependencies when we introduce them by ourselves within our own "easyverse" ;-)

from bayestestr.

haha totally true!

Although all the components (aside from the most front-end ones) of the easyverse (I like that though 😄!) have no to few external deps, so the splitting is mostly a convenience thing for developers for writing and maintaining rather than a weight issue for users.

But yes, we should try not overfragment it.

(but I still do think, for now, that the model's general metrics of fit/performance and parameters analysis aspects will be easier to work on if they are separate... but if the future we see that there is no need for having a dissociated performance and parameters packages, I will be all for merging them ☺️).

from bayestestr.