Fix guides

[malcolmbarrett]

Closes #146

[malcolmbarrett]

This change is causing an unusual bug in the status plots (or perhaps just detected by them). I thought maybe the new version of ggplot was unearthing a different bug but using the dev version of ggdag + the new ggplot works as expected

library(ggdag, warn.conflicts = FALSE)
test_dag <- dagify(
  y ~ x + w2 + w1,
  x ~ z1 + w1,
  z1 ~ w1 + v,
  z2 ~ w2 + v,
  w1 ~ ~w2,
  exposure = "x",
  outcome = "y"
)

test_dag <- tidy_dagitty(test_dag)

# right
ggdag_parents(test_dag, "x")

ggdag_children(test_dag, "v")

# wrong
ggdag_parents(test_dag, "y")

ggdag_children(test_dag, "x")

# right????
ggdag_parents(test_dag, "y", use_edges = FALSE) + geom_dag_edges()

ggdag_children(test_dag, "x", use_edges = FALSE) + geom_dag_edges()

^{Created on 2024-03-07 with reprex v2.1.0}

[malcolmbarrett]

It's not yet clear to me why, but this regression appears to be due to removing drop = FALSE in scale_color_discrete(drop = FALSE). Adding it back in fixes the legend.

I still suspect that this may be unearthing a pre-existing bug on the ggdag side.

[malcolmbarrett]

I have a working theory on this. I think the edge geom is filtering values in some capacity that is dropping single values of either "child" or "node" but then breaks() is adding them back in, resulting in a poor legend as ggplot doesn't know the value added by breaks() is a missing level

It's not clear to me why not using an edge in geom_dag() then adding one manually changes that process. Perhaps having the geoms as a list() means they get processed all at once by ggplot, whereas doing an edge after means it doesn't impact how the data are filtered?

[malcolmbarrett]

This is fixed in tests but I do believe there is a more robust way to deal with this. I'll file another issue to explore later