vlucas

vlucas

Co-founder of @techlahoma. Creator of BudgetSheet, Frisby.js, phpdotenv, valitron, and other open-source projects. Engineering Lead/Manager. FT Remote from OKC

Member Since 13 years ago

@Shopify, Oklahoma City, OK

Experience Points
690
follower
Lessons Completed
35
follow
Lessons Completed
414
stars
Best Reply Awards
91
repos

558 contributions in the last year

Pinned
⚡ Loads environment variables from `.env` to `getenv()`, `$_ENV` and `$_SERVER` automagically.
⚡ Valitron is a simple, elegant, stand-alone validation library with NO dependencies
⚡ Frisby is a REST API testing framework built on Jest that makes testing API endpoints easy, fast, and fun.
⚡ Lightweight validation library with NO dependencies. A nice Joi alternative with a similar API.
⚡ Mocks for Google Apps Script libraries, specifically around Spreadsheets
⚡ Featherweight key-based central store of state with zero dependencies
Activity
Jan
21
3 days ago
Activity icon
created tag

vlucas in vlucas/gasmask create tag v1.3.3

createdAt 2 days ago
push

vlucas push vlucas/gasmask

vlucas
vlucas

SpreadsheetApp: Add stub for newDataValidation()

commit sha: f340a8b16710ecb5cac74d90abde17175a563c3f

push time in 2 days ago
Activity icon
issue

vlucas issue comment Shopify/hydrogen

vlucas
vlucas

[WIP] SFAPI client PoC

Description

A PoC that shows how SFAPI client can be used in Hydrogen.

This PR only illustrates how the client can be used to replace the hardcoded gql fragments and queries - this branch will not work as is.

vlucas
vlucas

I like the way this looks. The code is more concise and the SFAPI handles things like versioning, pagination, metafields, connections, etc. so that Hydrogen can just focus on the framework and components.

Jan
18
6 days ago
pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

[Hydrogen reference]: Tailwind benefits

This PR:

vlucas
vlucas

Looks great! I like these changes. 👍

pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

[Hydrogen reference]: Tailwind benefits

This PR:

vlucas
vlucas
Activity icon
issue

vlucas issue comment Shopify/hydrogen

vlucas
vlucas

[Hydrogen reference]: Tailwind benefits

This PR:

vlucas
vlucas

I like these changes. Thanks! 👍

Jan
17
1 week ago
Activity icon
issue

vlucas issue comment vlucas/sheetquery

vlucas
vlucas

add getCells

Hello, I like and use your library to work on google sheet. I had to create border and to change color of a cell, so I added two methods on SheetQueryBuilder.

  const query = sheetQuery()
                  .from('Feuille 1')
                  .where((row) => row.H1 === 1 || row.H1 === 13);

  //cells is an array of range's row
  const cells = query.getCells();
  cells.forEach((cellRow) => {
    cellRow.setBackground('green'); // All the query's row are green
  })

  //cell is an array of range
  const cellsH1 = query.getCellsByColumns("H1");
  cellsH1.forEach((cell) => {
    cell.setBackground('red');  // Only the cell on H1 from the query's rows are red
  })
vlucas
vlucas

Can you provide an example on usage for the second parameter or getCellsByColumns and the intent behind that?

Activity icon
issue

vlucas issue comment vlucas/sheetquery

vlucas
vlucas

add getCells

Hello, I like and use your library to work on google sheet. I had to create border and to change color of a cell, so I added two methods on SheetQueryBuilder.

  const query = sheetQuery()
                  .from('Feuille 1')
                  .where((row) => row.H1 === 1 || row.H1 === 13);

  //cells is an array of range's row
  const cells = query.getCells();
  cells.forEach((cellRow) => {
    cellRow.setBackground('green'); // All the query's row are green
  })

  //cell is an array of range
  const cellsH1 = query.getCellsByColumns("H1");
  cellsH1.forEach((cell) => {
    cell.setBackground('red');  // Only the cell on H1 from the query's rows are red
  })
vlucas
vlucas

Thanks for this contribution. I will check it out and add some tests around it.

Jan
13
1 week ago
push

vlucas push vlucas/toystore

vlucas
vlucas

fix: package.json & package-lock.json to reduce vulnerabilities

The following vulnerabilities are fixed with an upgrade:

commit sha: 15523c273d5943d2ad1b26061df08805f278899e

push time in 1 week ago
Activity icon
created branch

vlucas in vlucas/toystore create branch snyk-fix-de2421c6fea372dcf307e469a8f98e26

createdAt 1 week ago
Jan
12
1 week ago
open pull request

vlucas wants to merge Shopify/hydrogen

vlucas
vlucas

feat: implement API routes

Description

Implement API routes: https://github.com/Shopify/hydrogen/issues/295

  • Route to pages with an api export
  • Error when a page exports both an api export and a default export
  • Support URL params
  • Support request body
  • Support workers
open pull request

vlucas wants to merge Shopify/hydrogen

vlucas
vlucas

feat: implement API routes

Description

Implement API routes: https://github.com/Shopify/hydrogen/issues/295

  • Route to pages with an api export
  • Error when a page exports both an api export and a default export
  • Support URL params
  • Support request body
  • Support workers
pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

feat: implement API routes

Description

Implement API routes: https://github.com/Shopify/hydrogen/issues/295

  • Route to pages with an api export
  • Error when a page exports both an api export and a default export
  • Support URL params
  • Support request body
  • Support workers
pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

feat: implement API routes

Description

Implement API routes: https://github.com/Shopify/hydrogen/issues/295

  • Route to pages with an api export
  • Error when a page exports both an api export and a default export
  • Support URL params
  • Support request body
  • Support workers
Jan
4
2 weeks ago
pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

fix: respond with 404 if route has no matches

Description

Fixes #387

Additional context

The server will respond with 404 if route has no matches.


Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
vlucas
vlucas

Can we get a test case for this?

pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

fix: respond with 404 if route has no matches

Description

Fixes #387

Additional context

The server will respond with 404 if route has no matches.


Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
vlucas
vlucas

Do we have a test for this?

pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

Usequery errors

feat: useShopQuery gives error hints if the storefront api responds with a 403

dx: add a launch config for VSCode users to debug the dev-server script

Description

Originally, we wanted to give devs a hint that their shopify.config.js was probably incorrect if the storefront API responded with a 403. In attempting to do this, I discovered that our custom useQuery implementation didn't surface errors - it placed errors on the data object with no way to tell if an error occurred or not. It also didn't check to see if the fetch's response was "ok."

So, with all those fixes in place, devs now get this error in their browser when their shopify config is wrong:

Error overlay with text: 'Failed to fetch the Storefront API. You may have a bald value in 'shopify.config.js''

as well as that same error in their server logs.


Additionally, I found it very helpful to use VSCode's built-in debugger to step through the server-side code, and finally found a config that should "just work" when using VSCode. I'm not sure if we actually want to keep that or not. If we do keep it, should it be documented on how to use it somewhere?

Additional context

  • Should we keep the .vscode/launch.json file?
  • Should we always throw an error when using useShopQuery, or...?
  • Should useQuery throw the response object, or something else? (I lean towards the raw response object, so that devs downstream can handle errors in their own way - just like we do in useShopQuery and a 403 response. That said, I'm still open to ideas)

Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
open pull request

vlucas wants to merge Shopify/hydrogen

vlucas
vlucas

Usequery errors

feat: useShopQuery gives error hints if the storefront api responds with a 403

dx: add a launch config for VSCode users to debug the dev-server script

Description

Originally, we wanted to give devs a hint that their shopify.config.js was probably incorrect if the storefront API responded with a 403. In attempting to do this, I discovered that our custom useQuery implementation didn't surface errors - it placed errors on the data object with no way to tell if an error occurred or not. It also didn't check to see if the fetch's response was "ok."

So, with all those fixes in place, devs now get this error in their browser when their shopify config is wrong:

Error overlay with text: 'Failed to fetch the Storefront API. You may have a bald value in 'shopify.config.js''

as well as that same error in their server logs.


Additionally, I found it very helpful to use VSCode's built-in debugger to step through the server-side code, and finally found a config that should "just work" when using VSCode. I'm not sure if we actually want to keep that or not. If we do keep it, should it be documented on how to use it somewhere?

Additional context

  • Should we keep the .vscode/launch.json file?
  • Should we always throw an error when using useShopQuery, or...?
  • Should useQuery throw the response object, or something else? (I lean towards the raw response object, so that devs downstream can handle errors in their own way - just like we do in useShopQuery and a 403 response. That said, I'm still open to ideas)

Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
vlucas
vlucas

Actually come to think of it... we should probably just not include this file. Can you add it to the .gitignore?

pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

Usequery errors

feat: useShopQuery gives error hints if the storefront api responds with a 403

dx: add a launch config for VSCode users to debug the dev-server script

Description

Originally, we wanted to give devs a hint that their shopify.config.js was probably incorrect if the storefront API responded with a 403. In attempting to do this, I discovered that our custom useQuery implementation didn't surface errors - it placed errors on the data object with no way to tell if an error occurred or not. It also didn't check to see if the fetch's response was "ok."

So, with all those fixes in place, devs now get this error in their browser when their shopify config is wrong:

Error overlay with text: 'Failed to fetch the Storefront API. You may have a bald value in 'shopify.config.js''

as well as that same error in their server logs.


Additionally, I found it very helpful to use VSCode's built-in debugger to step through the server-side code, and finally found a config that should "just work" when using VSCode. I'm not sure if we actually want to keep that or not. If we do keep it, should it be documented on how to use it somewhere?

Additional context

  • Should we keep the .vscode/launch.json file?
  • Should we always throw an error when using useShopQuery, or...?
  • Should useQuery throw the response object, or something else? (I lean towards the raw response object, so that devs downstream can handle errors in their own way - just like we do in useShopQuery and a 403 response. That said, I'm still open to ideas)

Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

Usequery errors

feat: useShopQuery gives error hints if the storefront api responds with a 403

dx: add a launch config for VSCode users to debug the dev-server script

Description

Originally, we wanted to give devs a hint that their shopify.config.js was probably incorrect if the storefront API responded with a 403. In attempting to do this, I discovered that our custom useQuery implementation didn't surface errors - it placed errors on the data object with no way to tell if an error occurred or not. It also didn't check to see if the fetch's response was "ok."

So, with all those fixes in place, devs now get this error in their browser when their shopify config is wrong:

Error overlay with text: 'Failed to fetch the Storefront API. You may have a bald value in 'shopify.config.js''

as well as that same error in their server logs.


Additionally, I found it very helpful to use VSCode's built-in debugger to step through the server-side code, and finally found a config that should "just work" when using VSCode. I'm not sure if we actually want to keep that or not. If we do keep it, should it be documented on how to use it somewhere?

Additional context

  • Should we keep the .vscode/launch.json file?
  • Should we always throw an error when using useShopQuery, or...?
  • Should useQuery throw the response object, or something else? (I lean towards the raw response object, so that devs downstream can handle errors in their own way - just like we do in useShopQuery and a 403 response. That said, I'm still open to ideas)

Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
open pull request

vlucas wants to merge Shopify/hydrogen

vlucas
vlucas

Usequery errors

feat: useShopQuery gives error hints if the storefront api responds with a 403

dx: add a launch config for VSCode users to debug the dev-server script

Description

Originally, we wanted to give devs a hint that their shopify.config.js was probably incorrect if the storefront API responded with a 403. In attempting to do this, I discovered that our custom useQuery implementation didn't surface errors - it placed errors on the data object with no way to tell if an error occurred or not. It also didn't check to see if the fetch's response was "ok."

So, with all those fixes in place, devs now get this error in their browser when their shopify config is wrong:

Error overlay with text: 'Failed to fetch the Storefront API. You may have a bald value in 'shopify.config.js''

as well as that same error in their server logs.


Additionally, I found it very helpful to use VSCode's built-in debugger to step through the server-side code, and finally found a config that should "just work" when using VSCode. I'm not sure if we actually want to keep that or not. If we do keep it, should it be documented on how to use it somewhere?

Additional context

  • Should we keep the .vscode/launch.json file?
  • Should we always throw an error when using useShopQuery, or...?
  • Should useQuery throw the response object, or something else? (I lean towards the raw response object, so that devs downstream can handle errors in their own way - just like we do in useShopQuery and a 403 response. That said, I'm still open to ideas)

Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
vlucas
vlucas

Comments are not valid JSON. Are we sure we can ship with these in this file?

pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

Usequery errors

feat: useShopQuery gives error hints if the storefront api responds with a 403

dx: add a launch config for VSCode users to debug the dev-server script

Description

Originally, we wanted to give devs a hint that their shopify.config.js was probably incorrect if the storefront API responded with a 403. In attempting to do this, I discovered that our custom useQuery implementation didn't surface errors - it placed errors on the data object with no way to tell if an error occurred or not. It also didn't check to see if the fetch's response was "ok."

So, with all those fixes in place, devs now get this error in their browser when their shopify config is wrong:

Error overlay with text: 'Failed to fetch the Storefront API. You may have a bald value in 'shopify.config.js''

as well as that same error in their server logs.


Additionally, I found it very helpful to use VSCode's built-in debugger to step through the server-side code, and finally found a config that should "just work" when using VSCode. I'm not sure if we actually want to keep that or not. If we do keep it, should it be documented on how to use it somewhere?

Additional context

  • Should we keep the .vscode/launch.json file?
  • Should we always throw an error when using useShopQuery, or...?
  • Should useQuery throw the response object, or something else? (I lean towards the raw response object, so that devs downstream can handle errors in their own way - just like we do in useShopQuery and a 403 response. That said, I'm still open to ideas)

Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
pull request

vlucas merge to Shopify/hydrogen

vlucas
vlucas

Usequery errors

feat: useShopQuery gives error hints if the storefront api responds with a 403

dx: add a launch config for VSCode users to debug the dev-server script

Description

Originally, we wanted to give devs a hint that their shopify.config.js was probably incorrect if the storefront API responded with a 403. In attempting to do this, I discovered that our custom useQuery implementation didn't surface errors - it placed errors on the data object with no way to tell if an error occurred or not. It also didn't check to see if the fetch's response was "ok."

So, with all those fixes in place, devs now get this error in their browser when their shopify config is wrong:

Error overlay with text: 'Failed to fetch the Storefront API. You may have a bald value in 'shopify.config.js''

as well as that same error in their server logs.


Additionally, I found it very helpful to use VSCode's built-in debugger to step through the server-side code, and finally found a config that should "just work" when using VSCode. I'm not sure if we actually want to keep that or not. If we do keep it, should it be documented on how to use it somewhere?

Additional context

  • Should we keep the .vscode/launch.json file?
  • Should we always throw an error when using useShopQuery, or...?
  • Should useQuery throw the response object, or something else? (I lean towards the raw response object, so that devs downstream can handle errors in their own way - just like we do in useShopQuery and a 403 response. That said, I'm still open to ideas)

Before submitting the PR, please make sure you do the following:

  • Add your change under the Unreleased heading in the package's CHANGELOG.md
  • Read the Contributing Guidelines
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
  • Update docs in this repository for your change, if needed
Jan
1
3 weeks ago
Activity icon
created tag
createdAt 3 weeks ago
Dec
20
1 month ago
Activity icon
issue

vlucas issue vlucas/sheetquery

vlucas
vlucas

SheetQuery cannot be found in G Script library.

I used the script id provided in the repo's readme and was unable to find it. Am I doing something wrong? Screenshot from 2021-07-04 17-15-53

Activity icon
issue

vlucas issue vlucas/sheetquery

vlucas
vlucas

[FEATURE REQUEST] Insert new row with primary key & auto increment

First of all, thank you so much for this library.

I am wondering if you plan to add a feature like adding a new row of data with a primary key and auto increment like MySQL has.

This would be an awesome feature and would complement your library. :)

Activity icon
issue

vlucas issue comment vlucas/sheetquery

vlucas
vlucas

[FEATURE REQUEST] Insert new row with primary key & auto increment

First of all, thank you so much for this library.

I am wondering if you plan to add a feature like adding a new row of data with a primary key and auto increment like MySQL has.

This would be an awesome feature and would complement your library. :)

vlucas
vlucas

Maintaining an auto-increment key is outside of the scope of this library.

The intent of this library is to facilitate easy read/write access to Google Sheets, not to turn Google Sheets into a full blown relational database.

That said, it should be feasible to create a set of small functions to do this for you using SheetQuery to read and write the data required.

Nov
28
1 month ago
started
started time in 1 month ago
Previous