我用我 0.4.0 的 echarts4r 试了下，跑出来的图看起来是正常的，然后我更新到了 0.4.4，也有问题，图中的点大小正常，但颜色都是黑色的，吓得我退回了 0.4.0

    meeeeeeeeo
    我的也是0.4.4，一样的现象，但是官网上类似的例子明明又是能跑出来的……

    quakes |>
    dplyr::mutate(color = mag) |>
    e_charts(x = lat) |>
    e_scatter_3d(
        y = long, z = depth,
        size = mag,
        color = mag,
        bind = stations,
        coordinate_system = "cartesian3D",
        name = "Fiji"
    ) |>
    e_x_axis_3d(min = -40, max = -10, name = "纬度") |>
    e_y_axis_3d(min = 165, max = 190, name = "经度") |>
    e_z_axis_3d(name = "深度") |>
    e_visual_map(
        serie = mag,
        type = "continuous",
        inRange = list(color = c('#4B0055', '#009B95', '#FDE333')),
        dimension = 4, # third dimension x = 0, y = 1, z = 2, color = 3, size = 4
        top = 20
    ) |>
    e_visual_map(
        serie = mag,
        type = "continuous",
        inRange = list(symbolSize = c(10, 30)),
        dimension = 3,
        bottom = 10
    ) |>
    e_tooltip() |>
    e_title(text = "斐济及其周边地震活动")

    然后我在数据里加了一列color=mag，图就正常了……即使后续的代码里看起来并没有显式用到这个color。

    我看不懂，但是我大受震撼.jpg

        fenguoerbian 官网上类似的例子明明又是能跑出来的

        官网的示例中坐标 x和y 都是字符型的分类变量，不知道是不是与之有关。

            fenguoerbian Cloud2016
            一通debug之后可能发现了问题所在，这里预期的做图数据应该是5列（3个座标，1个颜色，1个大小），但是出问题的图的做图数据只有4列。

            整个call的顺序是e_scatter_3d --> e_scatter_3d_ --> .build_data2，其中.build_data2源码是

            .build_data2 <- function(data, ...) {
  row.names(data) <- NULL
  data <- data |>
    dplyr::select(...)
  
  data <- unname(data)

  apply(data, 1, function(x) {
    list(value = unlist(x, use.names = FALSE))
  })
}

            在e_scatter_3d_ 调用 .build_data2的时候，使用的语句是

            data <- .build_data2(e$x$data[[i]], e$x$mapping$x, y, z, color, size)

            以楼主原本的代码而言，可以验证此时在e_scatter_3d_中，color和size都是字符串“mag"，于是原数据在后续的dplyr::select中只被提取到了1次。

            而我这个莫名其妙的能让图正常的修改，其实就是碰巧我在数据里加了一列叫做color的列，和这里传入的变量名color相同。所以如果在我那个修改里把新增的列叫做color_not_work，那这个图也不会正常生成。

            所以这里的核心就是，dplyr::select(...) 中多次选择同一列，结果只会返回1列。而我那个碰巧的做法，实际是这里提到的模糊的名称使用，而在这里恰好起效了。

            另外如果.build_data2(data, ...)的...里如果传入的实际上是列名的字符串，那么按照前述链接里的建议的话，为了消除语义中的模糊，可以修改成

            dplyr::select(tidyselect::all_of(c(...)))

            但是本质上从这里来看，同样的变量被多次选择，只会返回1次，于是做图数据缺了1列。不过消除歧义总是有好处的，比方说在这里，如果原始数据里有"y", "z"这样的列名，那么这里也会优先选取那两列，而不是传入的y,z参数中保存的列名。

                  fenguoerbian 所以，本质上，这里是 dplyr 或 tidyselect 包的 BUG？

                  因为正常来讲，将一个变量同时映射给气泡的颜色和大小（气泡图的常规做法）是正常的需求。

                      fenguoerbian 你可真是位人才。可惜这次 R 会议的报告时间都安排在北京时间的晚上，我这边实在是太早了。我看看后天早上我能不能六点爬起来听你的报告，见识一下本尊。

                          Cloud2016

                          我觉得这里有好几个问题：

                          1. select里多次选择同一列，只返回一次，这个可能是dplyr里确定好的策略了？那么可能就还是落在echarts4r这边来处理如果用户真的多次选择同一个数据的时候，这个构建做图数据的函数该怎么处理。

                          2. 另外就是目前的.build_data2函数里，确实是存在语义模糊的缺陷的。

                              Cloud2016

                              恩，我提交了一个，直接把.build_data 和.build_data2里的dplyr::select(data, ...)替换成了data[, c(...), drop = FALSE]，已经被merge了。

                              不过说实话我看utils.R里面有好几处都是用的dplyr::select(...)的做法，也不太好确定是不是这些其它位置也有类似的问题，或者我这样的修改是否带来新的问题。感觉使用中稳妥起见的话，不如就把输入数据里的变量名按照x,y,z,color,size准备一下。

                                  fenguoerbian 感谢，后面等维护者有空的时候发布新版！本来昨天想继续稍稍吐槽一下 dplyr， 它号称数据操作的语法，提供类似 SQL 的语义，但是又在这和 SQL 不一致，哎 😮‍💨！

                                    fenguoerbian 今天起晚了一点，没赶上你的报告，可惜了。我觉得我们可以举办一个小型 COS 坛友会，应该会比较有意思，比如每个人来一场五分钟闪电报告，像你这里的查虫过程和经验就很值得一讲。

                                        yihui 没事儿，而且有录屏哈～搞这种闪电报告也是个很好的形式，我就怕自己一下子刹不住车就开始话痨了。

                                          4 个月 后

                                          来晚了，echarts4r 的 debug 我常用的办法是用 |> e_inspect(json = TRUE, pretty = TRUE) 来查看输出的设置项，参考ECharts的文档看看有没有错。如果设置项里没有很多JS的函数设置的话，还可以直接把整块设置项丢到Echarts的在线编辑器中查看效果是否正常。再来判断到底是是自己写的，是echarts4r，还是ECharts本身的问题。