solidusio / solidus_graphql_api Goto Github PK
View Code? Open in Web Editor NEWGraphQL comes to Solidus!
License: BSD 3-Clause "New" or "Revised" License
GraphQL comes to Solidus!
License: BSD 3-Clause "New" or "Revised" License
We have the saveInAddressBook
mutation, but it always assumes the address is a shipping address. We should add a parameter to specify billing address when needed. It's something supported by the method it delegates to.
I'm evaluating Solidus. It appears looking back at posts a year ago that GraphQL was being pitched as the future for Solidus. It's now been 8 months since a release.. does that mean that this gem is really stable? Is GraphQL being abandoned as the future of Solidus? Trying to figure out how I would develop my application and whether it's better to build on the rest API or on GraphQL
Dependabot can't resolve your Ruby dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
Bundler::VersionConflict with message: Bundler could not find compatible versions for gem "codecov":
In Gemfile:
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
codecov (~> 0.1.16)
Could not find gem 'codecov (~> 0.1.16)', which is required by gem 'solidus_dev_support (~> 1.5.0)', in any of the sources.
Bundler could not find compatible versions for gem "rubocop":
In Gemfile:
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
rubocop-performance (~> 1.5) was resolved to 1.6.1, which depends on
rubocop (>= 0.71.0)
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
rubocop-rspec (~> 1.36) was resolved to 1.41.0, which depends on
rubocop (>= 0.68.1)
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
rubocop (~> 0.76.0)
Bundler could not find compatible versions for gem "solidus_core":
In Gemfile:
solidus was resolved to 2.11.0.alpha, which depends on
solidus_core (= 2.11.0.alpha)
solidus_auth_devise was resolved to 2.4.0, which depends on
solidus_core (>= 2.6, < 3)
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
solidus_core (>= 2.0, < 3)
solidus_graphql_api was resolved to 0.0.1, which depends on
solidus_core (>= 2.5, < 3)
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
Dependabot can't resolve your Ruby dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
Bundler::VersionConflict with message: Bundler could not find compatible versions for gem "solidus_core":
In Gemfile:
solidus was resolved to 3.1.0.alpha, which depends on
solidus_core (= 3.1.0.alpha)
solidus_graphql_api was resolved to 0.0.1, which depends on
solidus_core (>= 2.5, < 3)
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
Hi there! I'm hoping to use this gem in a Solidus 3.4 app to add some additional API functionality. I'm really interested in evaluating it and using it, but it hasn't received any updates in 1.5 years. When I try to bundle
in a Ruby 3.1 app, I get this error:
solidus_graphql_api was resolved to 0.2.0, which depends on
Ruby (~> 2.5)
Is this gem actively maintained? If so, will you all accept patches to update the gem to support Ruby 3.x and some modern versions of the GQL dependencies? Happy to help contribute, but I just want to ensure it's welcomed effort.
Thanks!
Currently, we're only supporting Relay's cursor-based pagination. This is a great algorithm, which usually outperforms traditional offset-based pagination. However, cursor pagination is usually used in infinite scroll UXs, as it tends to sort by a timestamp and, for instance, it currently doesn't support bidirectional pagination. This is a use case that often doesn't make sense for e-commerce, so it'd be good to support both algorithms.
Hey there,
Thanks for the GraphQL API for solidus.
This is not an actual issue with the gem itself but rather how complete it is feature wise. I am happy to assist if you could perhaps add a roadmap for this gem and outline areas that needs attention.
For example, I found these areas that needs work:
Dependabot can't resolve your Ruby dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
Bundler::VersionConflict with message: Bundler could not find compatible versions for gem "solidus_core":
In Gemfile:
solidus was resolved to 3.1.0.alpha, which depends on
solidus_core (= 3.1.0.alpha)
solidus_graphql_api was resolved to 0.0.1, which depends on
solidus_core (>= 2.5, < 3)
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
The playground and the docs seem to indicate you can filter products based on the taxon they're in. Neither of these work, both throw an error that you can't pass that as an argument.
{
products(query: {taxon: 4}) {
nodes {
name
}
}
}
{
products(query: {taxon: "4"}) {
nodes {
name
}
}
}
Mutation to implements:
Example, query:
query getProduct {
productBySlug(slug: "solidus-t-shirt") {
variants {
nodes {
optionValues {
nodes {
name
presentation
position
id
}
}
}
}
}
}
Result:
{
"data": {
"productBySlug": {
"name": "Solidus T-Shirt",
"variants": {
"nodes": [
{
"optionValues": {
"nodes": [
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
},
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
},
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
}
]
}
},
{
"optionValues": {
"nodes": [
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "Black",
"presentation": "Black",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTc="
},
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "Black",
"presentation": "Black",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTc="
}
]
}
},
{
"optionValues": {
"nodes": [
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "Small",
"presentation": "S",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTE="
},
{
"name": "White",
"presentation": "White",
"position": "2",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTg="
},
{
"name": "White",
"presentation": "White",
"position": "2",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTg="
}
]
}
},
{
"optionValues": {
"nodes": [
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
},
{
"name": "Medium",
"presentation": "M",
"position": "2",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTI="
},
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
},
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
}
]
}
},
{
"optionValues": {
"nodes": [
{
"name": "White",
"presentation": "White",
"position": "2",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTg="
},
{
"name": "Large",
"presentation": "L",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTM="
},
{
"name": "White",
"presentation": "White",
"position": "2",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTg="
},
{
"name": "Large",
"presentation": "L",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTM="
}
]
}
},
{
"optionValues": {
"nodes": [
{
"name": "Black",
"presentation": "Black",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTc="
},
{
"name": "Large",
"presentation": "L",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTM="
},
{
"name": "Large",
"presentation": "L",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTM="
},
{
"name": "Black",
"presentation": "Black",
"position": "1",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTc="
}
]
}
},
{
"optionValues": {
"nodes": [
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
},
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
},
{
"name": "Extra Large",
"presentation": "XL",
"position": "4",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTQ="
},
{
"name": "Blue",
"presentation": "Blue",
"position": "3",
"id": "U3ByZWU6Ok9wdGlvblZhbHVlLTk="
}
]
}
}
]
}
}
}
}
The database has no duplicates, so it's a matter of the query being made.
I want to add a variable to taxonomies, for example, slug.
The query I expect is
query {
taxonomiesByName(name: "Preset") {
nodes {
name
taxons {
nodes {
name
permalink
}
}
}
}
}
I added query_decorators.rb into app/graphql/types directory
# frozen_string_literal: true
module Graphql
module Types
module QueryDecorator
def self.prepended(base)
base.field :taxonomies_by_name, SolidusGraphqlApi::Types::Taxonomy.connection_type, null: false, description: 'Supported taxonomies by name' do
argument :name, String, required: true
end
end
def taxonomies_by_name(name:)
Spree::Taxonomy.find_by(name: name)
end
SolidusGraphqlApi::Types::Query.prepend self
end
end
end
When I call this query, I got an error.
{
"error": {
"message": "No connection implementation to wrap Spree::Taxonomy (#<Spree::Taxonomy:0x00007fb2c7d7e020>)",
"backtrace": [
...
How to fix it?
Update this extension so that it works with Solidus 3.0 by making sure the specs pass.
Add mutations to manage the user address book:
Currently, the Address type has both a stateName
string field and a state
object with a name
field. In Solidus, only one of them has a value.
Investigate whether or not it is possible to remove such redundancy. GraphQL union types come to mind.
Hello,
Thanks for the great work on this gem. I noticed while adding a taxons
field to Product
following the example here:
https://github.com/solidusio-contrib/solidus_graphql_api#adding-a-new-field
BatchLoader::HasManyThrough
ends up resolving the query and produces duplicate taxons for each product. Here's a sample query that's generated with the joins on some test data:
`SELECT `spree_taxons`.`id`, `spree_taxons`.`parent_id`, `spree_taxons`.`position`, `spree_taxons`.`taxonomy_id`, `spree_taxons`.`lft`, `spree_taxons`.`rgt`, `spree_taxons`.`icon_file_name`, `spree_taxons`.`icon_content_type`, `spree_taxons`.`icon_file_size`, `spree_taxons`.`icon_updated_at`, `spree_taxons`.`created_at`, `spree_taxons`.`updated_at`, `spree_taxons`.`depth` FROM `spree_taxons` INNER JOIN `spree_products_taxons` ON `spree_products_taxons`.`taxon_id` = `spree_taxons`.`id` WHERE `spree_products_taxons`.`product_id` IN (2, 8, 9, 10, 11, 12, 13, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 26, 29)
`
This happens here in BatchLoader::HasManyThrough
:
def retrieve_records_for(object_ids)
through_reflection = reflection.through_reflection
base_relation
.joins(through_reflection.name)
.where("#{through_reflection.table_name}.#{through_reflection.foreign_key}" => object_ids)
end
We have two potential solutions
distinct
when batching HasManyThrough
associations to prevent duplicate recordsThoughts? Please let me know if I'm missing something - happy to send in a PR once this is discussed.
Thanks!
Hey guys, I'm trying to install the gem into my project and the generator isn't generating anything in fact. Any thoughts?
Some presentation fields has been implemented, for example:
Such fields implement presentation logic that in Solidus has been implemented within models because on monolithic Rails apps models often happen to have have some presentation logic responsibilities.
GraphQL instead is meant to interact with storefront frontends, which should implement the whole presentation logic by themselves. For example, Price#display_amount
might use Price#currency
, Price#amount
and Intl.NumberFormat
in order to implement its price presentation logic.
Therefore, such fields are redundant and should be removed.
Following the conventions used in this PR #55 we should update also the other integration specs and remove the type specs:
Dependabot can't resolve your Ruby dependency files.
As a result, Dependabot couldn't update your dependencies.
The error Dependabot encountered was:
Bundler::VersionConflict with message: Bundler could not find compatible versions for gem "codecov":
In Gemfile:
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
codecov (~> 0.1.16)
Could not find gem 'codecov (~> 0.1.16)', which is required by gem 'solidus_dev_support (~> 1.5.0)', in any of the sources.
Bundler could not find compatible versions for gem "rubocop":
In Gemfile:
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
rubocop-rspec (~> 1.36) was resolved to 1.41.0, which depends on
rubocop (>= 0.68.1)
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
rubocop (~> 0.76.0)
Bundler could not find compatible versions for gem "solidus_core":
In Gemfile:
solidus was resolved to 2.11.0.alpha, which depends on
solidus_core (= 2.11.0.alpha)
solidus_auth_devise was resolved to 2.4.0, which depends on
solidus_core (>= 2.6, < 3)
solidus_dev_support (~> 1.5.0) was resolved to 1.5.0, which depends on
solidus_core (>= 2.0, < 3)
solidus_graphql_api was resolved to 0.0.1, which depends on
solidus_core (>= 2.5, < 3)
If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.
Needed to display the name associated to the ShippingRate
CurrencyType
like the Money::Currency
;currencies
(or available_currencies
?) to the StoreType
(Spree::Config.available_currencies
);CurrencyType
in the PriceType
instead of the old currency
and currency_symbol
fields (Spree::Price#display_amount.currency
)I noticed that the mutation next_checkout_state
behaviors differently than the API.
In the API:
def next
authorize! :update, @order, order_token
if !expected_total_ok?(params[:expected_total])
respond_with(@order, default_template: 'spree/api/orders/expected_total_mismatch', status: 400)
return
end
@order.next!
respond_with(@order, default_template: 'spree/api/orders/show', status: 200)
end
The mutation:
def resolve
current_order.next
{
order: current_order.reload,
errors: user_errors("order", current_order.errors)
}
end
You can see the API uses the bang version of the next method and it also verifies an expected total. Are these expected differences due to how you would like the GraphQL API to work? Or is it just an issue that should be logged and resolved? Curious if I should log other differences I notice like this as well.
Desired Behavior
For those testing out GraphQL but not yet ready to have it in production, it would be great to conditionally include the route.
It'd be helpful mainly to fetch only a country's states without having to workaround through iterating a generic result of a query without them and limiting through pagination.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.