feat: add TS solution to lc problem No.1293

[rain84]

No description provided.

[idoocs]

🤭 感谢你的提交，请检查你的改动是否符合以下项目规范。

1. 格式化

我们项目中各种编程语言代码（包括文档）所采用的格式化工具不同，提交 pr 之前必须确保代码、文档正确格式化。

• .{md,js,ts,php,sql,rs} 采用 prettier
• .{c,cpp,java} 采用 clang-format
• .{py} 采用 black
• .{go} 采用 gofmt
• 其它待完善

2. Git 提交信息

我们项目遵循 AngularJS Git Commit Message Conventions 规范，我们希望你的提交信息尽可能与项目保持一致。

• 新增或修改题解：feat: add/update solution(s) to lc problem(s): No.xxxx
• 修复错误：fix: xxxx
• 日常维护：chore: xxx

3. 其它补充

新增题解及代码时，需要创建 Solution.xxx 源代码文件（如果已存在，请确认算法是否更优，是则覆盖已有算法代码），同时，需要在 README.md 以及 README_EN.md 中添加对应的代码片段（英文文件中不要出现中文注释）
另外，编码风格（比如变量、函数的命名），尽量跟项目已有代码保持一致。

---

🤭 Thank you for your contribution. Please check if your changes comply with the following project specifications.

1. Formatting

We use different formatting tools for various programming languages (including documentation) in our project. You must ensure that the code and documentation are correctly formatted before submitting a pr.

• .{md,js,ts,php,sql,rs} use prettier
• .{c,cpp,java} use clang-format
• .{py} use black
• .{go} use gofmt
• Others to be improved

2. Git Commit Message

Our project follows the AngularJS Git Commit Message Conventions. We hope that your submission information is as consistent as possible with the project.

• Add or modify solutions: feat: add/update solution(s) to lc problem(s): No.xxxx
• Fix errors: fix: xxxx
• Routine maintenance: chore: xxx

3. Other notes

When adding solutions and code, you need to create a Solution.xxx source code file (if it already exists, please confirm whether the algorithm is better, if yes, overwrite the existing algorithm code), and at the same time, you need to add the corresponding code snippets in README.md and README_EN.md (do not have Chinese comments in the English file)
In addition, the coding style (such as the naming of variables and functions) should be as consistent as possible with the existing code in the project.

[yanglbme]

Hi @rain84 Here are a few suggestions:

1. Define m and n according to the description given in the problem, i.e., m = grid.length and n = grid[0].length. Our existing solution also defines them this way.
2. When using breadth-first search (BFS), we usually mark the node as visited in the vis array when we put it into the queue. This can prevent revisiting nodes that have already been added to the queue.
3. If a nextQ queue is defined, you only need to iterate through the original queue q without popping elements from q one by one.

[rain84]

@yanglbme Hi, friend!

Thanks for the helpful advises!
They help me become better

2. When using breadth-first search (BFS), we usually mark the node as visited in the vis array when we put it into the queue. This can prevent revisiting nodes that have already been added to the queue.

I am going through the LeetCode's crash course in DSA. And it uses the naming 'seen' instead of 'vis'. Tthat is why there is no need to abbreviate original word. How do you think, may be this approach is better?

[rain84]

Also I tried to define vis as a 3D-array ([n][m][k]), and there was no advantages between Set and string-hash.

1. With 3D array

2. With hash-Set

@yanglbme , what do you think about this?

[yanglbme]

@rain84

Hello, in this problem, storing the visited nodes in a hash table or a 3D array both result in a complexity of $O(m\times n\times k)$, with no difference in this regard. Based on my evaluations on the LeetCode Chinese site, the execution time is around 90ms.

If we use a hash table with strings, each time before enqueuing, we need to convert the node into a string and check if the string is in the hash table. This approach might not be as concise as using $vis[x][y][k]$.

[rain84]

@yanglbme

Thanks for nice explanation
I tested your solution on LeetCode and made shure there is no significant difference with mine.
I decided to keep solution with hash-sets, after some cosmetic changes (thank you for a good examples with your code!) it looks cleaner for me. But it is only my own IMHO )
If you are interested you can view it here.