profile
viewpoint
Scott smolinari Germany https://www.patreon.com/user?u=16255660 Like what I do? Help me do it more! Become a patron and get me that coffee!!! Link below.

quasarframework/quasar 16912

Quasar Framework - Build high-performance VueJS user interfaces in record time

quasarframework/app-extension-apollo 67

The official Quasar App-Extension for Apollo and GraphQL - Currently Beta!

quasarframework/rfcs 15

RFCs for Quasar Framework

claustres/quasar-templates 10

Quasar App Boilerplates

quasarframework/quasar-codesandbox 6

A Codesandbox Template

smolinari/PHP-Packer-Demo 1

The demonstration package for the Sitepoint article on Packer

smolinari/apollo 0

:rocket: Open source tools for GraphQL. Central repo for discussion.

smolinari/apollo-client 0

:rocket: A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server

smolinari/app-extension-apollo 0

The official Quasar App-Extension for Apollo and GraphQL - Currently Beta!

smolinari/app-extension-icon-factory 0

Make all the icons for your app. A quasar-1.0+ app-extension and stand-alone CLI.

pull request commentvuejs/rfcs

New `script setup` (without ref sugar)

@3nuc "vue-loader-v16": "npm:vue-loader@^16.0.0", This works for me in devDep

yyx990803

comment created time in an hour

issue commentquasarframework/quasar

Webpack 5 support

Regarding:

pug-plain-loader (used in docs) not updated since years, webpack 5 status support unknown

I'm using a forked version because as you noted, it hasn't been updated for a while. The proper version by Evan has a dependency error and doesn't work with pug v3. See Other Packages in the forked readme for details.

This only depends on the latest version of loader-utils by webpack, so I believe it will be compatible. I can test/confirm once ready to review.

IlCallo

comment created time in 2 hours

issue openedquasarframework/quasar

lang(uyghur): Partially written in Chinese

Describe the bug Thank you @Ansar-786 for: "add uyghur language pack" #7832

However, I noticed the 'Editor' section (lines 50-92) is all in Chinese. Was this on purpose or accidental oversight?

Codepen/jsFiddle/Codesandbox (required) Can be seen in the 'Editor' section of the Uyghur language file.

To Reproduce Can be seen in the 'Editor' section of the Uyghur language file.

Expected behavior All values to be in Uyghur or fallback to English (or Chinese in this case) but only when no value exists in the language.

Screenshots N/A

Platform (please complete the following information): OS: Linux(5.4.0-54-generic) - linux/x64 [Ubuntu 20.04.1 LTS (Focal Fossa)] Node: 12.20.0 NPM: 6.14.9 Yarn: 1.22.10 Browsers: Chrome, Firefox iOS: N/A Android: N/A Electron: N/A

Additional context

Below is a Google translation for the 'Editor' section:

  editor: {
    url: 'URL',
    bold: 'Bold',
    italic: 'ئىتالىيان',
    strikethrough: 'Strikethrough',
    underline: 'ئاستى سىزىق',
    unorderedList: 'تەرتىپسىز تىزىملىك',
    orderedList: 'زاكاز تىزىملىكى',
    subscript: 'مۇشتەرى',
    superscript: 'Superscript',
    hyperlink: 'Hyperlink',
    toggleFullscreen: 'تولۇق ئېكراننى ئالماشتۇرۇڭ',
    quote: 'نەقىل',
    left: 'سول تەڭگە',
    center: 'Center align',
    right: 'ئوڭ توغرىلاش',
    justify: 'توغرىلاشنى توغرىلاڭ',
    print: 'بېسىش',
    outdent: 'تەۋەككۈلچىلىكنى ئازايتىش',
    indent: 'تەۋەككۈلچىلىكنى ئاشۇرۇش',
    removeFormat: 'فورماتنى ئۆچۈرۈڭ',
    formatting: 'فورماتلاش',
    fontSize: 'خەت چوڭلۇقى',
    align: 'توغرىلاش',
    hr: 'توغرىسىغا قائىدە قىستۇرۇش',
    undo: 'ئەمەلدىن قالدۇرۇش',
    redo: 'Redo',
    heading1: 'Heading 1',
    heading2: 'Heading 2',
    heading3: 'Heading 3',
    heading4: 'Heading 4',
    heading5: 'Heading 5',
    heading6: 'Heading 6',
    paragraph: 'ئابزاس',
    code: 'كود',
    size1: 'بەك كىچىك',
    size2: 'ئازراق كىچىك',
    size3: 'نورمال',
    size4: 'ئوتتۇراھال چوڭ',
    size5: 'چوڭ',
    size6: 'بەك چوڭ',
    size7: 'ئەڭ چوڭ',
    defaultFont: 'كۆڭۈلدىكى خەت نۇسخىسى',
    viewSource: 'مەنبەنى كۆرۈش',
  },

I could submit a PR with the above but it's accuracy could be questionable.

@Ansar-786 would you please be able to review and correct the translations above and then update the language file with the new translations?

created time in 3 hours

issue commentnestjs/nest

Support custom logger better for startup logs

#1828 #2497 #1043 #507 And the one with most context and conversation #247

yissachar

comment created time in 4 hours

pull request commentquasarframework/quasar

fix: #8107 ability to customize redirect status code

Excellent work. Will merge it asap.

p1pchenk0

comment created time in 4 hours

issue commentnestjs/nest

Support custom logger better for startup logs

@kamilmysliwiec Can you please link to the issues? I did search and was not able to find anything that provided a solution, only issues like #3439 which just re-iterate the current problematic behaviour. Thanks!

yissachar

comment created time in 5 hours

push eventquasarframework/quasar

Razvan Stoenescu

commit sha 24783a3106b1a6fd0c10f6d2f20d8b45d7bcaecc

feat(docs): fixing small issues in multiple composition api files

view details

push time in 5 hours

pull request commentnestjs/nest

fix(microservices): listen method is void return type

Pull Request Test Coverage Report for Build 582cf39e-dd85-49c9-a194-c31fb6b8ce64

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 94.651%

Totals Coverage Status
Change from base Build 23fac820-c861-40be-bf3c-a307cbe03615: 0.0%
Covered Lines: 5008
Relevant Lines: 5291

💛 - Coveralls
kaznovac

comment created time in 5 hours

PR opened nestjs/nest

fix(microservices): listen method is void return type

state correct return type (void) on the NestMicroservice.listen method

PR Checklist

Please check if your PR fulfills the following requirements:

  • [x] The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
  • [ ] Tests for the changes have been added (for bug fixes / features)
  • [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

<!-- Please check the one that applies to this PR using "x". -->

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?

<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. --> return type is misleading this is not a breaking-change

Other information

+2 -2

0 comment

2 changed files

pr created time in 5 hours

pull request commentnestjs/nest

refactor: jsdoc fixes for INestApplication, INestMicroservice, MiddlewareConsumer and MiddlewareConfigProxy

Pull Request Test Coverage Report for Build ef028f9e-52a3-4b8c-8339-ef76233d7361

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 94.651%

Totals Coverage Status
Change from base Build 23fac820-c861-40be-bf3c-a307cbe03615: 0.0%
Covered Lines: 5008
Relevant Lines: 5291

💛 - Coveralls
kaznovac

comment created time in 5 hours

PR opened nestjs/nest

refactor: jsdoc fixes for INestApplication, INestMicroservice, MiddlewareConsumer and MiddlewareConfigProxy

this pr fixes some jsdoc typing in listed interfaces:

  • optional parameters (see https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html#param-and-returns)
  • rest/repeatable parameters (see https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html#more-examples and https://jsdoc.app/tags-param.html#multiple-types-and-repeatable-parameters)
  • solved some type inconsistencies (type from ts definition put in jsdoc)
  • removed double spaces after param keywoard

PR Checklist

Please check if your PR fulfills the following requirements:

  • [x] The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
  • [ ] Tests for the changes have been added (for bug fixes / features)
  • [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

<!-- Please check the one that applies to this PR using "x". -->

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?

<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. -->

Other information

+39 -39

0 comment

4 changed files

pr created time in 6 hours

issue commentapollographql/apollo-server

Error: "user" defined in resolvers, but not in schema

In my case, it was an even sillier mistake. I had accidentally put my mutations inside my query :laughing:

module.exports = {
   Query: {
      async getPosts () {
         try {
            const posts = await Post.find()
            return posts;
         } catch (err) {
            throw new Error(err)
         }
      },
      async getPost(_, { postId }) {
         try {
            const post = await Post.findById(postId)
   
            if (post) {
               return post
            } else {
               throw new Error('Post not found')
            }
         } catch (err) {
            throw new Error(err)
         }
      }
   },
   Mutation: {
      async createPost(_, { body }, context) {
         const user = checkAuth(context)
         console.log(user)

         const newPost = newPost({
            body,
            user: user.id,
            username: user.username,
            createdAt: new Date().toISOString
         })

         const post = await newPost.save 
         return post 
      }
   }
}
RomanADavis

comment created time in 6 hours

issue closedvuejs/vue

Why is there something "global"?

Full story - https://medium.com/@madyuskin/flux-vuex-are-wrong-and-outdated-61438de7c512

What problem does this feature solve?

Instead of global and non-global, there should be parent and child. And if a parent has no parent, you may call it global. Something like this can help: <pre> <code> export default { passdown: ['bar', 'foobar2'], data: () => ({ foo: null, bar: null }), methods: { foobar1() {}, foobar2() {} } } </code> </pre> Now any child has direct access to bar and foobar2 — no need to pass through all its parents. But I am sure in many cases it is an overkill just like Vuex.

What does the proposed API look like?

<pre> <code> export default { passdown: ['bar', 'foobar2'], data: () => ({ foo: null, bar: null }), methods: { foobar1() {}, foobar2() {} } } </code> </pre>

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 6 hours

Madyuskin

issue commentvuejs/vue

Why is there something "global"?

This sounds pretty much like inject/provide. FYI vuex is not necessary to build an application. If you think this deserves more discussion, you should give it a try on the RFC. I recommend you to also expose your points instead of only linking to an article

Madyuskin

comment created time in 6 hours

issue commentvuejs/vue

Unexpected token in createComponentInstanceForVnode when running dev

Sorry to bump this well over a month after it was addressed, but can the build process really not cope with same-line comments?

I see this was fixed by moving the comments to separate preceding lines. So is this is a practice that should always be observed for development of VueJS, or was this a quirky edge-case that doesn't warrant further investigation?

mitchellbryson

comment created time in 6 hours

push eventtauri-apps/tauri

Renovate Bot

commit sha d27d7cacf00c350ed0059b8065fbe4c705bf905f

chore(deps) Update Tauri JS CLI

view details

push time in 7 hours

pull request commentardatan/graphql-tools

fix(stitch) fix merged error paths from batched arrays

I don’t have strong feels... adjusting errors on the way out of batchDelegateToSchema seems easy enough. I was going to ask, is there a way to recognize ‘argsFromKeys’ within delegation bindings? If so, just recognizing that aspect of active subschema config would be sufficient. I suppose that doesn’t fix the issue for batchDelegateToSchema outside the context of stitching though. :/

On Sat, Nov 28, 2020 at 4:28 PM Yaacov Rydzinski notifications@github.com wrote:

Ack, you are completely right about this!

The "right" solution is to either traverse the result tree on every batchDelegateToSchema call and adjust every embedded error OR to somehow alert the CheckResult... transform that when it embeds the errors into the object by full path, it should transform the errors first.... But this should only happen when using batchDelegateToSchema and we know that the array result is actually not being returned as an array.... When delegating from list to list, error positions within the list need to be saved....

We have the ability to alter the default transforms passed to delegateToSchema using the delegation bindings argument...

But rather than changing all of that, keeping two setsb of bindings in sync, we should try to think of a simpler option

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ardatan/graphql-tools/pull/2288#issuecomment-735292647, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFRROB7TNJAEFIJVRAXGVLSSFTOTANCNFSM4UFRFQ2Q .

gmac

comment created time in 7 hours

pull request commentardatan/graphql-tools

fix(stitch) fix merged error paths from batched arrays

Ack, you are completely right about this!

The "right" solution is to either traverse the result tree on every batchDelegateToSchema call and adjust every embedded error OR to somehow alert the CheckResult... transform that when it embeds the errors into the object by full path, it should transform the errors first.... But this should only happen when using batchDelegateToSchema and we know that the array result is actually not being returned as an array.... When delegating from list to list, error positions within the list need to be saved....

We have the ability to alter the default transforms passed to delegateToSchema using the delegation bindings argument...

But rather than changing all of that, keeping two setsb of bindings in sync, we should try to think of a simpler option

gmac

comment created time in 8 hours

issue closedquasarframework/quasar

Error creating a new project with electron

Describe the bug I can't install quasar with electron. It seems like the installation process is never ending; probably a npm bug. I aborted the installation process after 20 minutes.

To Reproduce Steps to reproduce the behavior:

  1. quasar create quasar-app
  2. cd quasar-app
  3. quasar dev -m electron

Expected behavior Installation without any errors.

Screenshots image

Platform (please complete the following information): OS: Windows 10 64 bit Node: 15.3.0 NPM: 7.0.14

Additional context Add any other context about the problem here.

closed time in 8 hours

Zerotask

issue commentquasarframework/quasar

Error creating a new project with electron

Use yarn on Windows, please.

Zerotask

comment created time in 8 hours

pull request commentnestjs/nest

feat(core): expose app.locals to express adapter

Oops! I forgot to edit another file as I see it now. I will send another PR tomorrow. Meanwhile, can you tell me where I will write tests?

I'd probably say some sort of integration test (you can add it to integration) that sets the app.locals in the test setup, and has a controller that sends data back from the app.locals, that way you can check that things are being set properly and are retrievable. Reach out to me on Discord if you want some more guidance

msrumon

comment created time in 8 hours

pull request commentgraphql/graphql-spec

RFC: __typename is not valid at subscription root

Of course, then you need to repeat the same field collection algorithm that happened during field resolution on the server when processing the result, so we currently do that in graphql-tools only when we need to know the types of scalar fields. Perhaps a generic solution would be to annotate fields using aliases that would include the typename, that is yet another option, just would be easier I think if all of these options worked...

benjie

comment created time in 8 hours

issue openedquasarframework/quasar

Error creating a new project with electron

Describe the bug I can't install quasar with electron. It seems like the installation process is never ending; probably a npm bug. I aborted the installation process after 20 minutes.

To Reproduce Steps to reproduce the behavior:

  1. quasar create quasar-app
  2. cd quasar-app
  3. quasar dev -m electron

Expected behavior Installation without any errors.

Screenshots image

Platform (please complete the following information): OS: Windows 10 64 bit Node: 15.3.0 NPM: 7.0.14

Additional context Add any other context about the problem here.

created time in 8 hours

issue commentGraphQLGuide/apollo-datasource-mongodb

this.findOneById is not a function

same issue when using in reference for test propose

my solution is, call objInstance.initialize({context: {}}) manually

But I would still like to see a more elegant solution

ptvandi

comment created time in 8 hours

pull request commentnestjs/nest

feat(core): expose app.locals to express adapter

Oops! I forgot to edit another file as I see it now. I will send another PR tomorrow. Meanwhile, can you tell me where I will write tests?

msrumon

comment created time in 8 hours

pull request commentgraphql/graphql-spec

RFC: __typename is not valid at subscription root

Of course, you can save the request document and add __typename to all abstract fields and then combine request and result to know types of everything, including subscription root. That is another way. But seems like this way should also be allowed to work in terms of symmetry of the root types.

benjie

comment created time in 9 hours

push eventquasarframework/quasar

Jeff Galbraith

commit sha 426818629ad5099847b87c0669b21dc323c3b8c2

chore(docs): Flex playground - further update

view details

Jeff Galbraith

commit sha 213b9a2a127388a30519ae324f55245713665f35

feat(docs): MorphUtils composition work

view details

push time in 9 hours

pull request commentgraphql/graphql-spec

RFC: __typename is not valid at subscription root

It would be helpful I think if this would be valid to allow for a completely typed result to be passed to result transformers. Otherwise result transformers have to be passed additional state in terms of which operation type was sent and treat the data field differently than inner fields during processing, at least for subscriptions.

benjie

comment created time in 9 hours

issue commentardatan/graphql-tools

WrapFields Incompatibility with Subscriptions

Related: https://github.com/graphql/graphql-spec/pull/776

tylermenezes

comment created time in 9 hours

pull request commentnestjs/nest

feat(core): expose app.locals to express adapter

To be honest, I have never written tests for any of the codes I've written in my entire life. But if I get some assistance, I can write some. This simple API doesn't do much, so I think 1-2 cases should be fine... What do you think?

msrumon

comment created time in 9 hours

more