Rshiny output function breaks when using $ operator and filter












1















I'm trying to build a shiny app very closely based on a previous one I have (which works), albeit with a different (though similarly structured) data object underneath. After changing all the variable and object names, I got the following error:




Warning: Error in filter_impl: Evaluation error: $ operator is invalid
for atomic vectors.




I found a couple of seemingly relevant pages in my searches online:



$ operator is invalid for atomic vectors :: R shiny



https://github.com/rstudio/shiny/issues/1823



Unfortunately the $ operator error seems to be quite a general error message, and neither of these seemed to specifically address my problem. After some tinkering paring back various elements, I found I could render the plots and tables in the app, provided I didn't use attempt to filter on any of the input fields.



For instance, the following ouptut worked, fine, including the switch that allowed me to turn the whole plot on and off, and alter the heading of the graph with a text input called filter1.



output$emoPlot <- renderPlotly({

if(input$prefilterswitch == "OFF"){
df <- dtm_EMO %>%
clusterer(input$clusters)

plot <- df %>%
left_join(EMO_ALL, by = "Work_Order") %>%
ggplot(aes(x = date, y = as.factor(cluster), col = MILL, shape = as.factor(PART), text = Equipment_Description_Line_1, text2 = Work_Order))+
geom_point()+
guides(col = "none")+
ggtitle(label = input$filter1)
ggplotly(plot, tooltip = c("x", "y", "col", "text", "text2", "size"))

}

})


However, if I add line that seeks to filter on one of those inputs, like this:



output$emoPlot <- renderPlotly({


if(input$prefilterswitch == "OFF"){
df <- dtm_EMO %>%
filter(str_detect(combined, input$prefilterswitch %>% tolower()) ==T) %>%
clusterer(input$clusters)

plot <- df %>%
left_join(EMO_ALL, by = "Work_Order") %>%
ggplot(aes(x = date, y = as.factor(cluster), col = MILL, shape = as.factor(PART), text = Equipment_Description_Line_1, text2 = Work_Order))+
geom_point()+
guides(col = "none")+
ggtitle(label = input$filter1)
ggplotly(plot, tooltip = c("x", "y", "col", "text", "text2", "size"))

}

})


Then I get my error, and no plot:




Warning: Error in filter_impl: Evaluation error: $ operator is invalid
for atomic vectors.




I've had a play with rending a table output, using renderTable aswell, and get the same problem. I can use inputs, but not with functions like filter(), and mutate() also has the same problem.



I suspected that perhaps the issue was to do with the inputs, but all of the switches and text fields render find in the app, and they seem to work, just not with those functions.



That's about as much as I've been able to narrow it down. It's a little frustrating since the ability to apply multiple filters is quite important to the purpose of the app. Any help would be appreciated!










share|improve this question























  • Not all inputs and variables are "set" the first time these reactive expressions will attempt to run. It's good practice to start a block with something like req(input$cluster) (see ?req), and nothing beyond that in the chunk will execute until input$cluster has a valid value. You can include multiple input variables in that req; you can even involve arbitrary expressions that evaluate to a number, boolean, or just about anything.

    – r2evans
    Nov 21 '18 at 22:39











  • Maybe you need to req(input$prefilterswitch) to avoid it being NULL when the input is initialized? But it's hard to tell without a minimal working example. - I saw @r2evans comment too late..

    – ismirsehregal
    Nov 21 '18 at 22:44













  • req() works for preventing an error, but still having trouble with getting the filter evaluated. Will keep playing with it.

    – Aidan Morrison
    Nov 22 '18 at 3:44











  • did you try base::subset instead of filter? If this is indeed a problem with the filter function, I see no reason to not use subset instead.

    – Nutle
    Nov 22 '18 at 15:30


















1















I'm trying to build a shiny app very closely based on a previous one I have (which works), albeit with a different (though similarly structured) data object underneath. After changing all the variable and object names, I got the following error:




Warning: Error in filter_impl: Evaluation error: $ operator is invalid
for atomic vectors.




I found a couple of seemingly relevant pages in my searches online:



$ operator is invalid for atomic vectors :: R shiny



https://github.com/rstudio/shiny/issues/1823



Unfortunately the $ operator error seems to be quite a general error message, and neither of these seemed to specifically address my problem. After some tinkering paring back various elements, I found I could render the plots and tables in the app, provided I didn't use attempt to filter on any of the input fields.



For instance, the following ouptut worked, fine, including the switch that allowed me to turn the whole plot on and off, and alter the heading of the graph with a text input called filter1.



output$emoPlot <- renderPlotly({

if(input$prefilterswitch == "OFF"){
df <- dtm_EMO %>%
clusterer(input$clusters)

plot <- df %>%
left_join(EMO_ALL, by = "Work_Order") %>%
ggplot(aes(x = date, y = as.factor(cluster), col = MILL, shape = as.factor(PART), text = Equipment_Description_Line_1, text2 = Work_Order))+
geom_point()+
guides(col = "none")+
ggtitle(label = input$filter1)
ggplotly(plot, tooltip = c("x", "y", "col", "text", "text2", "size"))

}

})


However, if I add line that seeks to filter on one of those inputs, like this:



output$emoPlot <- renderPlotly({


if(input$prefilterswitch == "OFF"){
df <- dtm_EMO %>%
filter(str_detect(combined, input$prefilterswitch %>% tolower()) ==T) %>%
clusterer(input$clusters)

plot <- df %>%
left_join(EMO_ALL, by = "Work_Order") %>%
ggplot(aes(x = date, y = as.factor(cluster), col = MILL, shape = as.factor(PART), text = Equipment_Description_Line_1, text2 = Work_Order))+
geom_point()+
guides(col = "none")+
ggtitle(label = input$filter1)
ggplotly(plot, tooltip = c("x", "y", "col", "text", "text2", "size"))

}

})


Then I get my error, and no plot:




Warning: Error in filter_impl: Evaluation error: $ operator is invalid
for atomic vectors.




I've had a play with rending a table output, using renderTable aswell, and get the same problem. I can use inputs, but not with functions like filter(), and mutate() also has the same problem.



I suspected that perhaps the issue was to do with the inputs, but all of the switches and text fields render find in the app, and they seem to work, just not with those functions.



That's about as much as I've been able to narrow it down. It's a little frustrating since the ability to apply multiple filters is quite important to the purpose of the app. Any help would be appreciated!










share|improve this question























  • Not all inputs and variables are "set" the first time these reactive expressions will attempt to run. It's good practice to start a block with something like req(input$cluster) (see ?req), and nothing beyond that in the chunk will execute until input$cluster has a valid value. You can include multiple input variables in that req; you can even involve arbitrary expressions that evaluate to a number, boolean, or just about anything.

    – r2evans
    Nov 21 '18 at 22:39











  • Maybe you need to req(input$prefilterswitch) to avoid it being NULL when the input is initialized? But it's hard to tell without a minimal working example. - I saw @r2evans comment too late..

    – ismirsehregal
    Nov 21 '18 at 22:44













  • req() works for preventing an error, but still having trouble with getting the filter evaluated. Will keep playing with it.

    – Aidan Morrison
    Nov 22 '18 at 3:44











  • did you try base::subset instead of filter? If this is indeed a problem with the filter function, I see no reason to not use subset instead.

    – Nutle
    Nov 22 '18 at 15:30
















1












1








1








I'm trying to build a shiny app very closely based on a previous one I have (which works), albeit with a different (though similarly structured) data object underneath. After changing all the variable and object names, I got the following error:




Warning: Error in filter_impl: Evaluation error: $ operator is invalid
for atomic vectors.




I found a couple of seemingly relevant pages in my searches online:



$ operator is invalid for atomic vectors :: R shiny



https://github.com/rstudio/shiny/issues/1823



Unfortunately the $ operator error seems to be quite a general error message, and neither of these seemed to specifically address my problem. After some tinkering paring back various elements, I found I could render the plots and tables in the app, provided I didn't use attempt to filter on any of the input fields.



For instance, the following ouptut worked, fine, including the switch that allowed me to turn the whole plot on and off, and alter the heading of the graph with a text input called filter1.



output$emoPlot <- renderPlotly({

if(input$prefilterswitch == "OFF"){
df <- dtm_EMO %>%
clusterer(input$clusters)

plot <- df %>%
left_join(EMO_ALL, by = "Work_Order") %>%
ggplot(aes(x = date, y = as.factor(cluster), col = MILL, shape = as.factor(PART), text = Equipment_Description_Line_1, text2 = Work_Order))+
geom_point()+
guides(col = "none")+
ggtitle(label = input$filter1)
ggplotly(plot, tooltip = c("x", "y", "col", "text", "text2", "size"))

}

})


However, if I add line that seeks to filter on one of those inputs, like this:



output$emoPlot <- renderPlotly({


if(input$prefilterswitch == "OFF"){
df <- dtm_EMO %>%
filter(str_detect(combined, input$prefilterswitch %>% tolower()) ==T) %>%
clusterer(input$clusters)

plot <- df %>%
left_join(EMO_ALL, by = "Work_Order") %>%
ggplot(aes(x = date, y = as.factor(cluster), col = MILL, shape = as.factor(PART), text = Equipment_Description_Line_1, text2 = Work_Order))+
geom_point()+
guides(col = "none")+
ggtitle(label = input$filter1)
ggplotly(plot, tooltip = c("x", "y", "col", "text", "text2", "size"))

}

})


Then I get my error, and no plot:




Warning: Error in filter_impl: Evaluation error: $ operator is invalid
for atomic vectors.




I've had a play with rending a table output, using renderTable aswell, and get the same problem. I can use inputs, but not with functions like filter(), and mutate() also has the same problem.



I suspected that perhaps the issue was to do with the inputs, but all of the switches and text fields render find in the app, and they seem to work, just not with those functions.



That's about as much as I've been able to narrow it down. It's a little frustrating since the ability to apply multiple filters is quite important to the purpose of the app. Any help would be appreciated!










share|improve this question














I'm trying to build a shiny app very closely based on a previous one I have (which works), albeit with a different (though similarly structured) data object underneath. After changing all the variable and object names, I got the following error:




Warning: Error in filter_impl: Evaluation error: $ operator is invalid
for atomic vectors.




I found a couple of seemingly relevant pages in my searches online:



$ operator is invalid for atomic vectors :: R shiny



https://github.com/rstudio/shiny/issues/1823



Unfortunately the $ operator error seems to be quite a general error message, and neither of these seemed to specifically address my problem. After some tinkering paring back various elements, I found I could render the plots and tables in the app, provided I didn't use attempt to filter on any of the input fields.



For instance, the following ouptut worked, fine, including the switch that allowed me to turn the whole plot on and off, and alter the heading of the graph with a text input called filter1.



output$emoPlot <- renderPlotly({

if(input$prefilterswitch == "OFF"){
df <- dtm_EMO %>%
clusterer(input$clusters)

plot <- df %>%
left_join(EMO_ALL, by = "Work_Order") %>%
ggplot(aes(x = date, y = as.factor(cluster), col = MILL, shape = as.factor(PART), text = Equipment_Description_Line_1, text2 = Work_Order))+
geom_point()+
guides(col = "none")+
ggtitle(label = input$filter1)
ggplotly(plot, tooltip = c("x", "y", "col", "text", "text2", "size"))

}

})


However, if I add line that seeks to filter on one of those inputs, like this:



output$emoPlot <- renderPlotly({


if(input$prefilterswitch == "OFF"){
df <- dtm_EMO %>%
filter(str_detect(combined, input$prefilterswitch %>% tolower()) ==T) %>%
clusterer(input$clusters)

plot <- df %>%
left_join(EMO_ALL, by = "Work_Order") %>%
ggplot(aes(x = date, y = as.factor(cluster), col = MILL, shape = as.factor(PART), text = Equipment_Description_Line_1, text2 = Work_Order))+
geom_point()+
guides(col = "none")+
ggtitle(label = input$filter1)
ggplotly(plot, tooltip = c("x", "y", "col", "text", "text2", "size"))

}

})


Then I get my error, and no plot:




Warning: Error in filter_impl: Evaluation error: $ operator is invalid
for atomic vectors.




I've had a play with rending a table output, using renderTable aswell, and get the same problem. I can use inputs, but not with functions like filter(), and mutate() also has the same problem.



I suspected that perhaps the issue was to do with the inputs, but all of the switches and text fields render find in the app, and they seem to work, just not with those functions.



That's about as much as I've been able to narrow it down. It's a little frustrating since the ability to apply multiple filters is quite important to the purpose of the app. Any help would be appreciated!







r shiny






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 21 '18 at 22:32









Aidan MorrisonAidan Morrison

82




82













  • Not all inputs and variables are "set" the first time these reactive expressions will attempt to run. It's good practice to start a block with something like req(input$cluster) (see ?req), and nothing beyond that in the chunk will execute until input$cluster has a valid value. You can include multiple input variables in that req; you can even involve arbitrary expressions that evaluate to a number, boolean, or just about anything.

    – r2evans
    Nov 21 '18 at 22:39











  • Maybe you need to req(input$prefilterswitch) to avoid it being NULL when the input is initialized? But it's hard to tell without a minimal working example. - I saw @r2evans comment too late..

    – ismirsehregal
    Nov 21 '18 at 22:44













  • req() works for preventing an error, but still having trouble with getting the filter evaluated. Will keep playing with it.

    – Aidan Morrison
    Nov 22 '18 at 3:44











  • did you try base::subset instead of filter? If this is indeed a problem with the filter function, I see no reason to not use subset instead.

    – Nutle
    Nov 22 '18 at 15:30





















  • Not all inputs and variables are "set" the first time these reactive expressions will attempt to run. It's good practice to start a block with something like req(input$cluster) (see ?req), and nothing beyond that in the chunk will execute until input$cluster has a valid value. You can include multiple input variables in that req; you can even involve arbitrary expressions that evaluate to a number, boolean, or just about anything.

    – r2evans
    Nov 21 '18 at 22:39











  • Maybe you need to req(input$prefilterswitch) to avoid it being NULL when the input is initialized? But it's hard to tell without a minimal working example. - I saw @r2evans comment too late..

    – ismirsehregal
    Nov 21 '18 at 22:44













  • req() works for preventing an error, but still having trouble with getting the filter evaluated. Will keep playing with it.

    – Aidan Morrison
    Nov 22 '18 at 3:44











  • did you try base::subset instead of filter? If this is indeed a problem with the filter function, I see no reason to not use subset instead.

    – Nutle
    Nov 22 '18 at 15:30



















Not all inputs and variables are "set" the first time these reactive expressions will attempt to run. It's good practice to start a block with something like req(input$cluster) (see ?req), and nothing beyond that in the chunk will execute until input$cluster has a valid value. You can include multiple input variables in that req; you can even involve arbitrary expressions that evaluate to a number, boolean, or just about anything.

– r2evans
Nov 21 '18 at 22:39





Not all inputs and variables are "set" the first time these reactive expressions will attempt to run. It's good practice to start a block with something like req(input$cluster) (see ?req), and nothing beyond that in the chunk will execute until input$cluster has a valid value. You can include multiple input variables in that req; you can even involve arbitrary expressions that evaluate to a number, boolean, or just about anything.

– r2evans
Nov 21 '18 at 22:39













Maybe you need to req(input$prefilterswitch) to avoid it being NULL when the input is initialized? But it's hard to tell without a minimal working example. - I saw @r2evans comment too late..

– ismirsehregal
Nov 21 '18 at 22:44







Maybe you need to req(input$prefilterswitch) to avoid it being NULL when the input is initialized? But it's hard to tell without a minimal working example. - I saw @r2evans comment too late..

– ismirsehregal
Nov 21 '18 at 22:44















req() works for preventing an error, but still having trouble with getting the filter evaluated. Will keep playing with it.

– Aidan Morrison
Nov 22 '18 at 3:44





req() works for preventing an error, but still having trouble with getting the filter evaluated. Will keep playing with it.

– Aidan Morrison
Nov 22 '18 at 3:44













did you try base::subset instead of filter? If this is indeed a problem with the filter function, I see no reason to not use subset instead.

– Nutle
Nov 22 '18 at 15:30







did you try base::subset instead of filter? If this is indeed a problem with the filter function, I see no reason to not use subset instead.

– Nutle
Nov 22 '18 at 15:30














1 Answer
1






active

oldest

votes


















0














I am pretty sure that the problem is the use of non standard evaluation in filter. In



 filter(str_detect(combined, input$prefilterswitch %>% tolower()))


you have input$prefilterswitch ... which normally in filter would be invalid because it is not just giving a column name from combined (even though we actually know that it is. I think there is probably a check in filter that automatically throws an error if there is a $. My usual solution to this is to create the object prior to starting your piping, so something like



 prefilterswitch <- input$prefilterswitch


And then reference that in the filter statement. Also with a Boolean you don't need ==T.
Alternatively you can go into rlang.






share|improve this answer
























  • Thanks for this, still haven’t got it to work. Can stop it breaking, but not actually get the filtering done. Will work on a minimal working example with some public data.

    – Aidan Morrison
    Nov 22 '18 at 4:24













  • Also try adding the dplyr:: name space.

    – Elin
    Nov 22 '18 at 4:29






  • 1





    A new day, some fresh eyes, and it turns out your answer works! I had a couple other trivial errors adding to the confusion. Thanks very much!

    – Aidan Morrison
    Nov 22 '18 at 22:01











  • If it works you could accept it.

    – Elin
    Nov 23 '18 at 2:10











  • Sorry! A bit new to this! Thanks again

    – Aidan Morrison
    Nov 29 '18 at 23:37











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53421362%2frshiny-output-function-breaks-when-using-operator-and-filter%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














I am pretty sure that the problem is the use of non standard evaluation in filter. In



 filter(str_detect(combined, input$prefilterswitch %>% tolower()))


you have input$prefilterswitch ... which normally in filter would be invalid because it is not just giving a column name from combined (even though we actually know that it is. I think there is probably a check in filter that automatically throws an error if there is a $. My usual solution to this is to create the object prior to starting your piping, so something like



 prefilterswitch <- input$prefilterswitch


And then reference that in the filter statement. Also with a Boolean you don't need ==T.
Alternatively you can go into rlang.






share|improve this answer
























  • Thanks for this, still haven’t got it to work. Can stop it breaking, but not actually get the filtering done. Will work on a minimal working example with some public data.

    – Aidan Morrison
    Nov 22 '18 at 4:24













  • Also try adding the dplyr:: name space.

    – Elin
    Nov 22 '18 at 4:29






  • 1





    A new day, some fresh eyes, and it turns out your answer works! I had a couple other trivial errors adding to the confusion. Thanks very much!

    – Aidan Morrison
    Nov 22 '18 at 22:01











  • If it works you could accept it.

    – Elin
    Nov 23 '18 at 2:10











  • Sorry! A bit new to this! Thanks again

    – Aidan Morrison
    Nov 29 '18 at 23:37
















0














I am pretty sure that the problem is the use of non standard evaluation in filter. In



 filter(str_detect(combined, input$prefilterswitch %>% tolower()))


you have input$prefilterswitch ... which normally in filter would be invalid because it is not just giving a column name from combined (even though we actually know that it is. I think there is probably a check in filter that automatically throws an error if there is a $. My usual solution to this is to create the object prior to starting your piping, so something like



 prefilterswitch <- input$prefilterswitch


And then reference that in the filter statement. Also with a Boolean you don't need ==T.
Alternatively you can go into rlang.






share|improve this answer
























  • Thanks for this, still haven’t got it to work. Can stop it breaking, but not actually get the filtering done. Will work on a minimal working example with some public data.

    – Aidan Morrison
    Nov 22 '18 at 4:24













  • Also try adding the dplyr:: name space.

    – Elin
    Nov 22 '18 at 4:29






  • 1





    A new day, some fresh eyes, and it turns out your answer works! I had a couple other trivial errors adding to the confusion. Thanks very much!

    – Aidan Morrison
    Nov 22 '18 at 22:01











  • If it works you could accept it.

    – Elin
    Nov 23 '18 at 2:10











  • Sorry! A bit new to this! Thanks again

    – Aidan Morrison
    Nov 29 '18 at 23:37














0












0








0







I am pretty sure that the problem is the use of non standard evaluation in filter. In



 filter(str_detect(combined, input$prefilterswitch %>% tolower()))


you have input$prefilterswitch ... which normally in filter would be invalid because it is not just giving a column name from combined (even though we actually know that it is. I think there is probably a check in filter that automatically throws an error if there is a $. My usual solution to this is to create the object prior to starting your piping, so something like



 prefilterswitch <- input$prefilterswitch


And then reference that in the filter statement. Also with a Boolean you don't need ==T.
Alternatively you can go into rlang.






share|improve this answer













I am pretty sure that the problem is the use of non standard evaluation in filter. In



 filter(str_detect(combined, input$prefilterswitch %>% tolower()))


you have input$prefilterswitch ... which normally in filter would be invalid because it is not just giving a column name from combined (even though we actually know that it is. I think there is probably a check in filter that automatically throws an error if there is a $. My usual solution to this is to create the object prior to starting your piping, so something like



 prefilterswitch <- input$prefilterswitch


And then reference that in the filter statement. Also with a Boolean you don't need ==T.
Alternatively you can go into rlang.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 21 '18 at 22:40









ElinElin

5,27121636




5,27121636













  • Thanks for this, still haven’t got it to work. Can stop it breaking, but not actually get the filtering done. Will work on a minimal working example with some public data.

    – Aidan Morrison
    Nov 22 '18 at 4:24













  • Also try adding the dplyr:: name space.

    – Elin
    Nov 22 '18 at 4:29






  • 1





    A new day, some fresh eyes, and it turns out your answer works! I had a couple other trivial errors adding to the confusion. Thanks very much!

    – Aidan Morrison
    Nov 22 '18 at 22:01











  • If it works you could accept it.

    – Elin
    Nov 23 '18 at 2:10











  • Sorry! A bit new to this! Thanks again

    – Aidan Morrison
    Nov 29 '18 at 23:37



















  • Thanks for this, still haven’t got it to work. Can stop it breaking, but not actually get the filtering done. Will work on a minimal working example with some public data.

    – Aidan Morrison
    Nov 22 '18 at 4:24













  • Also try adding the dplyr:: name space.

    – Elin
    Nov 22 '18 at 4:29






  • 1





    A new day, some fresh eyes, and it turns out your answer works! I had a couple other trivial errors adding to the confusion. Thanks very much!

    – Aidan Morrison
    Nov 22 '18 at 22:01











  • If it works you could accept it.

    – Elin
    Nov 23 '18 at 2:10











  • Sorry! A bit new to this! Thanks again

    – Aidan Morrison
    Nov 29 '18 at 23:37

















Thanks for this, still haven’t got it to work. Can stop it breaking, but not actually get the filtering done. Will work on a minimal working example with some public data.

– Aidan Morrison
Nov 22 '18 at 4:24







Thanks for this, still haven’t got it to work. Can stop it breaking, but not actually get the filtering done. Will work on a minimal working example with some public data.

– Aidan Morrison
Nov 22 '18 at 4:24















Also try adding the dplyr:: name space.

– Elin
Nov 22 '18 at 4:29





Also try adding the dplyr:: name space.

– Elin
Nov 22 '18 at 4:29




1




1





A new day, some fresh eyes, and it turns out your answer works! I had a couple other trivial errors adding to the confusion. Thanks very much!

– Aidan Morrison
Nov 22 '18 at 22:01





A new day, some fresh eyes, and it turns out your answer works! I had a couple other trivial errors adding to the confusion. Thanks very much!

– Aidan Morrison
Nov 22 '18 at 22:01













If it works you could accept it.

– Elin
Nov 23 '18 at 2:10





If it works you could accept it.

– Elin
Nov 23 '18 at 2:10













Sorry! A bit new to this! Thanks again

– Aidan Morrison
Nov 29 '18 at 23:37





Sorry! A bit new to this! Thanks again

– Aidan Morrison
Nov 29 '18 at 23:37




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53421362%2frshiny-output-function-breaks-when-using-operator-and-filter%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

If I really need a card on my start hand, how many mulligans make sense? [duplicate]

Alcedinidae

Can an atomic nucleus contain both particles and antiparticles? [duplicate]