Passing an array to imagePath #8
Comments
deadband
changed the title
|
Hey @deadband, thanks for this! This is a duplicate of this issue, in which I recommended using multiple instances of the plugin, but I don't think that's the best solution long term. I would love to add this functionality out of the box, I think it makes sense. I don't have time this week to look at adding this, but PRs welcome and it's top of the list for features to add. Thanks again! |
|
Thanks for the response @graysonhicks, I will look into a way to accomplish this when I have a moment. The multiple instance approach may not work for me as I never know what the length of the array will be. I also agree with you that this would not be the cleanest approach. Once again, thanks for your contribution with this plugin! |
|
Hi @graysonhicks, @deadband, Thanks a lot for the work on this plugin! I am quite new to gatsby ecosystem and I am definitely not a javascript expert but I tried to work on a similar feature since I needed it for a new project. In my case I need to handle this kind of schemas please feel free to add any comment or remark. I am not sure it is a PR material for now: here is the URL: darrazo@b054601 |
Closed
bensbigolbeard
added a commit
to bensbigolbeard/gatsby-plugin-remote-images
that referenced
this issue
Jul 16, 2019
Before, if the objects holding your remote images were in an array, the `lodash .get` method could not traverse those arrays to target the correct objects. These changes add opt-in support for this functionality by extending `lodash .get`'s syntax to indicate where the arrays need to be traversed. Adding an array literal in the `path` option on the node holding the array, like `myArrayNode[].imageUrl`. This does diverge from `lodash .get` syntax, but here were the considerations: * If we didn't have some explicit indication in the path, like `myArrayNode.imageUrl`, you would still have a value that was invalid to pass to `.get` as-is, but the code would internally have to hand-hold each node to see if it was an object or array before proceeding, essentially meaning you would have to reimplement `.get` and its safeguards. * The `[]` suffix is a pattern already found in other tools, like `TypeScript`, to indicate a node is an array, so it should be relatively recognizable to users * When no `[]` is supplied, the current logic reverts to the existing functionality, delegating object traversal entirely to `.get` There has also been interest to support [leaf nodes which contain an array of urls](graysonhicks#8). These changes don't add this support, but it should be possible to achieve with a bit of rework without having to rethink the entire approach.
bensbigolbeard
added a commit
to bensbigolbeard/gatsby-plugin-remote-images
that referenced
this issue
Jul 16, 2019
Before, if the objects holding your remote images were in an array, the `lodash .get` method could not traverse those arrays to target the correct objects. These changes add opt-in support for this functionality by extending `lodash .get`'s syntax to indicate where the arrays need to be traversed. Adding an array literal in the `path` option on the node holding the array, like `myArrayNode[].imageUrl`, triggers the logic to create image nodes for each object in `myArrayNode`. This does diverge from `lodash .get` syntax, but here were the considerations: * If we didn't have some explicit indication in the path, like `myArrayNode.imageUrl`, you would still have a value that was invalid to pass to `.get` as-is, but the code would internally have to hand-hold each node to see if it was an object or array before proceeding, essentially meaning you would have to reimplement `.get` and its safeguards. * The `[]` suffix is a pattern already found in other tools, like `TypeScript`, to indicate a node is an array, so it should be relatively recognizable to users * When no `[]` is supplied, the current logic reverts to the existing functionality, delegating object traversal entirely to `.get` There has also been interest to support [leaf nodes which contain an array of urls](graysonhicks#8). These changes don't add this support, but it should be possible to achieve with a bit of rework without having to rethink the entire approach.
bensbigolbeard
added a commit
to bensbigolbeard/gatsby-plugin-remote-images
that referenced
this issue
Jul 16, 2019
Before, if the objects holding your remote images were in an array, the `lodash .get` method could not traverse those arrays to target the correct objects. These changes add opt-in support for this functionality by extending `lodash .get`'s syntax to indicate where the arrays need to be traversed. Adding an array literal in the `path` option on the node holding the array, like `myArrayNode[].imageUrl`, triggers the logic to create image nodes for each object in `myArrayNode`. This does diverge from `lodash .get` syntax, but here were the considerations: * If we didn't have some explicit indication in the path, like `myArrayNode.imageUrl`, you would still have a value that was invalid to pass to `.get` as-is, but the code would internally have to hand-hold each node to see if it was an object or array before proceeding, essentially meaning you would have to reimplement `.get` and its safeguards. * The `[]` suffix is a pattern already found in other tools, like `TypeScript`, to indicate a node is an array, so it should be relatively recognizable to users * When no `[]` is supplied, the current logic reverts to the existing functionality, delegating object traversal entirely to `.get` There has also been interest to support [leaf nodes which contain an array of urls](graysonhicks#8). These changes don't add this support, but it should be possible to achieve with a bit of rework without having to rethink the entire approach.
bensbigolbeard
added a commit
to bensbigolbeard/gatsby-plugin-remote-images
that referenced
this issue
Jul 22, 2019
Before, if the objects holding your remote images were in an array, the `lodash .get` method could not traverse those arrays to target the correct objects. These changes add opt-in support for this functionality by extending `lodash .get`'s syntax to indicate where the arrays need to be traversed. Adding an array literal in the `path` option on the node holding the array, like `myArrayNode[].imageUrl`, triggers the logic to create image nodes for each object in `myArrayNode`. This does diverge from `lodash .get` syntax, but here were the considerations: * If we didn't have some explicit indication in the path, like `myArrayNode.imageUrl`, you would still have a value that was invalid to pass to `.get` as-is, but the code would internally have to hand-hold each node to see if it was an object or array before proceeding, essentially meaning you would have to reimplement `.get` and its safeguards. * The `[]` suffix is a pattern already found in other tools, like `TypeScript`, to indicate a node is an array, so it should be relatively recognizable to users * When no `[]` is supplied, the current logic reverts to the existing functionality, delegating object traversal entirely to `.get` There has also been interest to support [leaf nodes which contain an array of urls](graysonhicks#8). These changes don't add this support, but it should be possible to achieve with a bit of rework without having to rethink the entire approach.
bensbigolbeard
added a commit
to bensbigolbeard/gatsby-plugin-remote-images
that referenced
this issue
Jul 22, 2019
Before, if the objects holding your remote images were in an array, the `lodash .get` method could not traverse those arrays to target the correct objects. These changes add opt-in support for this functionality by extending `lodash .get`'s syntax to indicate where the arrays need to be traversed. Adding an array literal in the `path` option on the node holding the array, like `myArrayNode[].imageUrl`, triggers the logic to create image nodes for each object in `myArrayNode`. This does diverge from `lodash .get` syntax, but here were the considerations: * If we didn't have some explicit indication in the path, like `myArrayNode.imageUrl`, you would still have a value that was invalid to pass to `.get` as-is, but the code would internally have to hand-hold each node to see if it was an object or array before proceeding, essentially meaning you would have to reimplement `.get` and its safeguards. * The `[]` suffix is a pattern already found in other tools, like `TypeScript`, to indicate a node is an array, so it should be relatively recognizable to users * When no `[]` is supplied, the current logic reverts to the existing functionality, delegating object traversal entirely to `.get` There has also been interest to support [leaf nodes which contain an array of urls](graysonhicks#8). These changes don't add this support, but it should be possible to achieve with a bit of rework without having to rethink the entire approach.
bensbigolbeard
added a commit
to bensbigolbeard/gatsby-plugin-remote-images
that referenced
this issue
Jul 22, 2019
Before, if the objects holding your remote images were in an array, the `lodash .get` method could not traverse those arrays to target the correct objects. These changes add opt-in support for this functionality by extending `lodash .get`'s syntax to indicate where the arrays need to be traversed. Adding an array literal in the `path` option on the node holding the array, like `myArrayNode[].imageUrl`, triggers the logic to create image nodes for each object in `myArrayNode`. This does diverge from `lodash .get` syntax, but here were the considerations: * If we didn't have some explicit indication in the path, like `myArrayNode.imageUrl`, you would still have a value that was invalid to pass to `.get` as-is, but the code would internally have to hand-hold each node to see if it was an object or array before proceeding, essentially meaning you would have to reimplement `.get` and its safeguards. * The `[]` suffix is a pattern already found in other tools, like `TypeScript`, to indicate a node is an array, so it should be relatively recognizable to users * When no `[]` is supplied, the current logic reverts to the existing functionality, delegating object traversal entirely to `.get` There has also been interest to support [leaf nodes which contain an array of urls](graysonhicks#8). These changes don't add this support, but it should be possible to achieve with a bit of rework without having to rethink the entire approach.
bensbigolbeard
added a commit
to bensbigolbeard/gatsby-plugin-remote-images
that referenced
this issue
Jul 24, 2019
Before, if the objects holding your remote images were in an array, the `lodash .get` method could not traverse those arrays to target the correct objects. These changes add opt-in support for this functionality by extending `lodash .get`'s syntax to indicate where the arrays need to be traversed. Adding an array literal in the `path` option on the node holding the array, like `myArrayNode[].imageUrl`, triggers the logic to create image nodes for each object in `myArrayNode`. This does diverge from `lodash .get` syntax, but here were the considerations: * If we didn't have some explicit indication in the path, like `myArrayNode.imageUrl`, you would still have a value that was invalid to pass to `.get` as-is, but the code would internally have to hand-hold each node to see if it was an object or array before proceeding, essentially meaning you would have to reimplement `.get` and its safeguards. * The `[]` suffix is a pattern already found in other tools, like `TypeScript`, to indicate a node is an array, so it should be relatively recognizable to users * When no `[]` is supplied, the current logic reverts to the existing functionality, delegating object traversal entirely to `.get` There has also been interest to support [leaf nodes which contain an array of urls](graysonhicks#8). These changes don't add this support, but it should be possible to achieve with a bit of rework without having to rethink the entire approach.
bensbigolbeard
added a commit
to bensbigolbeard/gatsby-plugin-remote-images
that referenced
this issue
Aug 19, 2019
Before, if the objects holding your remote images were in an array, the `lodash .get` method could not traverse those arrays to target the correct objects. These changes add opt-in support for this functionality by extending `lodash .get`'s syntax to indicate where the arrays need to be traversed. Adding an array literal in the `path` option on the node holding the array, like `myArrayNode[].imageUrl`, triggers the logic to create image nodes for each object in `myArrayNode`. This does diverge from `lodash .get` syntax, but here were the considerations: * If we didn't have some explicit indication in the path, like `myArrayNode.imageUrl`, you would still have a value that was invalid to pass to `.get` as-is, but the code would internally have to hand-hold each node to see if it was an object or array before proceeding, essentially meaning you would have to reimplement `.get` and its safeguards. * The `[]` suffix is a pattern already found in other tools, like `TypeScript`, to indicate a node is an array, so it should be relatively recognizable to users * When no `[]` is supplied, the current logic reverts to the existing functionality, delegating object traversal entirely to `.get` There has also been interest to support [leaf nodes which contain an array of urls](graysonhicks#8). These changes don't add this support, but it should be possible to achieve with a bit of rework without having to rethink the entire approach.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi Grayson - great work on the plugin, thanks for putting this out for the community! Not really an issue with your plugin, but I was hoping maybe you could shed some light on something.
My question: Is it possible to pass an array of paths to imagePath? For example, the API I am trying to use has a response something like this:
"links": {
"images": [
"https://foo.com/image1.jpg",
"https://foo.com/image2.jpg",
"https://foo.com/image3.jpg",
"https://foo.com/image4.jpg",
"https://foo.com/image5.jpg",
"https://foo.com/image6.jpg",
"https://foo.com/image7.jpg",
]
},
From what I understand, imagePath is looking for a singular path and not an array of paths. Am I trying to make it do something its not able to do or am I just overlooking something simple?
I went to the lodash docs for _.get but still had no luck. Thanks in advance!
The text was updated successfully, but these errors were encountered: