I'm trying to fetch the current user in Sanity CMS.
I found this code snippet which demonstrates use of userStore
But I don't understand how I can configure my project to accept this module lookup
import userStore from 'part:#sanity/base/user';
It throws an import error Cannot find module 'part:#sanity/base/user'. Which makes sense as its a non standard node module.
How can I resolve this so the module is found?
Or alternatively anyone know another way to fetch the current user?
Inspecting that #sanity source I can see base/lib/datastores which has a userStore it's just not obvious how to consume this.
So this example hook works and returns the User. Sanity is taking care of the module resolution. It's an IDE error not a runtime error in Sanity.
(╯°□°）╯︵ ┻━┻
Their advice is to ignore these un resolved module warnings for part imports.
"eslintConfig": {
"rules": {
"import/no-unresolved": [2, { "ignore": ["^(all|part):"] }]
}
},
Related
I've recently wanted to get back into programming, and I know that Apollo GraphQL has moved to an asynchronous way to firing up the server per their documentation.
Since switching (and following docs), I can't get my server to fire up, and I don't know why.
When the server attempts to run, it hangs on the execution of .start() on my ApolloServer instance, even though I'm giving it (what I think) are both valid type definitions and resolvers.
The current iteration of my tiny boilerplate project is located here on CodeSandbox.
When I run this code locally, I receive the following error (which isn't shown on CS?):
Argument type {typeDefs: DocumentNode, resolvers: {Query: {hello(): string}}} is not assignable to parameter type ApolloServerExpressConfig
This error is on line 9, where the instance of ApolloServer is created.
I don't know what I'm doing wrong. I was previously using babel-plugin-import-graphql but switched away from that to using a normal JS import w/ the gql tag just to be safe. The problem appears to be with the resolver map, which doesn't make sense:
const resolvers = {
Query: {
hello: () => "world!"
}
};
export default resolvers;
Anyway, thanks in advance! Would love to get this sorted out today. I think if I don't, I'll end up just switching over to using Meteor for full-stack stuff and then use React for the front-end and just not worry about it anymore.
First, I'd like to explain that I have a Vue component repository that is responsible for displaying data retrieved from an http service. Rather than the component itself managing the same data retrieval per instance and spamming the client with network requests, I've managed to find a solution which allows another component to be mounted to the root directly (which I've dubbed as a "Service" due to its similarity to Angular) to manage the data those components need instead. This works great and other components can access it via Vue.prototype (via this.$TestService.value). It has some caveats but for the most part it accomplishes exactly what I needed. This may be uncommon, but those that use Vuex are using a similar methodology and I don't want to use the store paradigm.
I've made a very simple Vue JsFiddle to show this in action...
https://jsfiddle.net/spronkets/8v31tcfd/18
Now, to the point... I'm using #testing-library/vue, #vue/test-utils, and Jest to test the components and get test coverage and now I get errors anytime I run the tests due to the service not existing on the Vue.prototype during the test execution. I don't want to mock out the functionality of the "Service" layer, so does anyone have a solution to test these root-mounted components? I've tried manually exporting the services (unmounted and mounted) and including them in the mock section as well as importing the files directly into the test files but the "Service" is always undefined when the component is trying to retrieve the value and ONLY during test execution...
I've also created a simple repository modelled after the Vue component repository I am working with below...
https://github.com/kcrossman/VueServiceExample
To get started, clone the repo and follow the README.md included in the repo. Thanks!
I would go against using the real service if it is asyncronous, but if you just want to register it to be available you can follow the mock instructions but instead of mocking with an object just import the real service. Although after seeing your TestService implementation you will need to separate the real service from the service registration and export it to be able to register it in local vue.
You need to create and prepare your custom Vue instance in your tests in order to use any custom functionalities in your unit tests (like stores, routers, and anything else). (You can use your real modules with the custom instance, don't have to mock anything.)
In your case you should create a new Vue instance with "createLocalVue" function from '#vue/test-utils' and apply your custom prototype functionalities on that. After that you can write proper test cases accessing that custom features as well.
Update:
For those that might be referring to this in the future, Vue Plugins might be a better solution for this kind of functionality.
I stumbled along this issue in GitHub and that led me to the fix I made below:
https://github.com/testing-library/vue-testing-library/issues/113
Specifically, this comment by user nikravi:
ok, I found the fix. The trick was to add
import Vue from "vue";
import Vuetify from "vuetify";
Vue.use(Vuetify);
and then the render() works without warnings.
After I manually imported Vue and set Vue.prototype.$TestService = TestService directly in the unit test, it got passed that error. Personally, I think this is pretty silly, but it worked.
After this worked, I also found that you can access the Vue instance directly within the render callback (from #testing-library/vue), so I finished on this code instead of importing Vue:
render(TestComponent, {}, vue => {
vue.prototype.$TestService = TestService;
});
I've included all the commits to solve my issue in the repo I posted previously:
https://github.com/kcrossman/VueServiceExample
Some of the tests were malformed but once I made those changes, the tests started to work and I updated some other files to be a bit nicer for people to refer to.
This weekend i tryed to test a package "A" from my meteor app.
This package depends on another package "B" that defines all collections. So the package "B" expose all required collections.
The package "A" expose a main object that have some methods that use the collections exposed in "B".
I want to replace some collections by a code like this :
myCol = {
"findOne": return {_id: 1, "name": ben}
}
But it fails. This code is ok from tinytest.add code, but in the methods of the package "A", it still uses the original Collection variables. I've seen in the build folder that everything is re-written by the build system, so i wonder what is the best way to test my code without depending on those Collection variables.
I have some ideas like storing those variables in a main object that has get/set methods. It might allow me to change everything when i do test.
Thanks for help
Here is the sample app : https://github.com/MeteorLyon/tutorial-package-dependancy-testing
Follow the README.md to run different test.
If you find a solution it's great.
If you are looking for stubs, I'd highly recommend using sinon. Specifically, have a look at the stubs and the sandbox portions of the docs. You can find atmosphere packages here. Here's a quick example:
Tinytest.add('my test', sinon.test(function(test) {
// this is sandboxed stub - we are writing to a global object
// but it will be restored at the end of the test
test.stub(Meteor, 'userId', function() {
return USER_ID;
});
// let's do the same thing with a collection
test.stub(Posts, 'findOne', function() {
return {_id: 1, name: 'ben'};
});
var post = Posts.findOne();
test.equal(post.name, 'ben');
}));
Keep in mind that tinytest is an integration test framework, so you may get better tests by fully utilizing both package's APIs. With respect to testing collection interactions, we've found its better to not stub very much and just insert and cleanup as needed. But that's pretty general advice - there may be some specific reason why this can't work in your particular use case.
I've been looking at using Aloha for a project but I'm completely stumped by the documentation. I'm trying to create a repository following the documentation and I have this so far:
requirejs.config({
paths: {
'jquery': "http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min",
'aloha': "http://cdn.aloha-editor.org/latest/lib/aloha",
},
});
define(
['jquery'],
function($) {
"use strict";
require(['aloha'], function(localAloha) {
console.debug(localAloha);
console.debug(Aloha.AbstractRepository);
});
return {};
}
);
Now. This tries to pull Aloha and jQuery from an appropriate CDN, and it works fine. However, despite what the Aloha documentation tells me, localAloha is not defined (it appears Aloha doesn't return itself) but that's not a problem since my that point it's in the global namespace anyway.
More frustrating when trying to define a repository is the fact that Aloha.AbstractRepository is undefined, despite all the examples, and code from live projects like the Drupal Aloha plugin, telling that all I need to do is extend Aloha.AbstractRepository.
Does anyone have any idea what's going on here? Aloha looks great, and is perfect for what I have in mind, but it's proven to be very difficult to actually get it working.
here is some code which should help you.
a php script is reading files from direcotries (eg. upload dir) and generates a json file with that information. that json is in the format which can be used by a js file (repository api) to tell aloha editor what's in your repository: http://ge.tt/1VJqium/v/0?c
I am using PHP-activerecord in kohana and using its auth module by calling function :
User::create_user("Name", "Name", "Name", "Name");
But seeing error : ErrorException [ Fatal Error ]: Class 'Arm' not found
I have added kohana-activerecord in bootstrap.php and also enabled Auth module. arm.php is in kohana-activerecord/classes/.
Can someone please help understand how to locate Class arm and remove this error. This will be of great help.
Assuming you're using https://github.com/devi/kohana-activerecord, the simplest answer is to load the class manually.
require_once('/kohana-activerecord/classes/arm.php') in your code, and do that until you have all of your dependencies loaded. I'm not entirely sure how the Kohana-Auth library is meant to load properly, and it has no real useful documentation on its github page. But I'll assume just manually loading the classes will be fine as it hasn't been updated for a couple years.